Rules evaluated during PingCastle Healthcheck

Date: 2024-11-13 - Engine version: 3.3.0.1

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
Account take over
Old trust protocol
Audit
Network topography
ACL Check
SID Filtering
Backup
Object configuration
Admin control
SIDHistory
Certificate take over
Obsolete OS
Control paths
Trust impermeability
Golden ticket
Old authentication protocols
Delegation Check
Trust inactive
Local group vulnerability
Provisioning
Irreversible change
Trust with Azure
Network sniffing
Replication
Privilege control
Pass-the-credential
Vulnerability management
Read-Only Domain Controllers
Password retrieval
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.

Check if all cluster are using regular password change practices.

Rule ID:

S-PwdLastSet-Cluster

Description:

The purpose is to ensure that the regular change of cluster account is active.

Technical Explanation:

The algorithm identifies clusters by checking three conditions:
1. The account is active, as indicated by the UserAccountControl flag not being set to 2.
2. The account was created at least three years ago but has been used within the last 45 days according to the attribute lastlogontimestamp.
3. The password was last set at least three years prior to the most recent login.

Advised Solution:


Certain accounts on Windows server clusters have maintained static passwords for over three years, suggesting a lack of secret refreshes.

To determine why the password hasn’t been updated, you must examine the cluster configuration and event logs.
Please consult the cited reference document to carry out this process.

Introduced in:

3.3.0.0

Points:

5 points if present

Documentation:

https://learn.microsoft.com/en-us/windows-server/failover-clustering/configure-ad-accounts
[FR]ANSSI - Windows server cluster accounts with passwords unchanged for more than 3 years (vuln2_password_change_cluster_no_change_3years)2
[US]STIG V-63653 - The computer account password must not be prevented from being reset.
[US]STIG V-3373 - The maximum age for machine account passwords is not set to requirements.
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Check if all computers are using regular password change practices.

Rule ID:

S-PwdLastSet-45

Description:

The purpose is to ensure that the regular change of computer account passwords is active

Technical Explanation:

By default, all computers automatically change their AD password every 30 days.
Changing regularly secrets like passwords ensures that they are not used in side channel attacks.
Also with the default possibility to create up to 10 computers accounts, these accounts may be seen as a backdoor.

This audit program considers this as an anomaly between 45 days and 90 days.
Also this rule is the companion for the rule S-PwdLastSet-90

Advised Solution:


Some security agencies report the absence of password change as an indicator of compromise.

If it is not the case, check the following registry keys:
* HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange: must be set to 0 or inexistent;
* HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge: must be set to 30.

For Linux systems, the password change may not be enabled by default - solutions exist, see the link in documentation, like a daily cron job to run msktutil --auto-update.

Introduced in:

2.9.0.0

Points:

5 points if present

Documentation:

https://support.microsoft.com/en-us/help/154501/how-to-disable-automatic-machine-account-password-changes
https://access.redhat.com/discussions/1283873
[FR]ANSSI - Servers with passwords unchanged for more than 45 days (vuln3_password_change_server_no_change_45)3
[US]STIG V-63653 - The computer account password must not be prevented from being reset.
[US]STIG V-3373 - The maximum age for machine account passwords is not set to requirements.
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Check if all computers have changed their passwords in the last 3 months.

Rule ID:

S-PwdLastSet-90

Description:

The purpose is to ensure that all computer accounts have their password changed in the last 3 months

Technical Explanation:

By default, all computers automatically change their AD password every 30 days.
Changing regularly secrets like passwords ensures that they are not used in side channel attacks.
Also with the default possibility to create up to 10 computers accounts, these accounts may be seen as a backdoor.

This audit program considers this as an anomaly starting with 90 days.
Also this rule is the companion for the rule S-PwdLastSet-45 which does the same between 45 and 90 days

Advised Solution:


Some security agencies report the absence of password change as an indicator of compromise.

If it is not the case, check the following registry keys:
* HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange: must be set to 0 or inexistent;
* HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge: must be set to 30.

For Linux systems, the password change may not be enabled by default - solutions exist, see the link in documentation, like a daily cron job to run msktutil --auto-update.

Introduced in:

2.9.0.0

Points:

15 points if present

Documentation:

https://support.microsoft.com/en-us/help/154501/how-to-disable-automatic-machine-account-password-changes
https://access.redhat.com/discussions/1283873
[FR]ANSSI - Servers with passwords unchanged for more than 90 days (vuln2_password_change_server_no_change_90)2
[US]STIG V-63653 - The computer account password must not be prevented from being reset.
[US]STIG V-3373 - The maximum age for machine account passwords is not set to requirements.
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Check if all DC are active.

Rule ID:

S-DC-Inactive

Description:

The purpose is to ensure that every DC is active.

Technical Explanation:

Domain Controllers are user accounts with powerful privileges.
While an active Domain Controller changes its password every 30 days, an inactive account can be involved in a domain compromise.
Indeed, another account, which has rights over this object, may reset the password of this account without being noticed.

Advised Solution:

You have to demote the DC object using the procedure referenced in the documentation section.

Introduced in:

2.9.0.0

Points:

5 points per discovery

Documentation:

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/demoting-domain-controllers-and-domains--level-200-
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R45 [paragraph.3.6.6.2]
[FR]ANSSI - Inactive domain controllers (vuln1_password_change_inactive_dc)1
[MITRE]Mitre Att&ck - Mitigation - User Account Management

Check if all DC are using regular password change practices.

Rule ID:

S-PwdLastSet-DC

Description:

The purpose is to ensure that the regular change of computer account is active on Domain Controllers.

Technical Explanation:

By default, each computers automatically change its password every 30 days. This is the same case for domain controllers.
Changing regularly secrets like passwords ensures that they are not used in side channel attacks.
For exemple, using DCSync to export the hash of a domain controller password, then reusing it in a silver attack to create Kerberos tickets.

This audit program considers this as an anomaly after 45 days.

Advised Solution:


Some security agencies report the absence of password change as an indicator of compromise.

If it is not the case, check the following registry keys:
* HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange: must be set to 0 or inexistent;
* HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge: must be set to 30.

Introduced in:

2.9.0.0

Points:

5 points per discovery

Documentation:

https://support.microsoft.com/en-us/help/154501/how-to-disable-automatic-machine-account-password-changes
[FR]ANSSI - Domain controllers with passwords unchanged for more than 45 days (vuln1_password_change_dc_no_change)1
[US]STIG V-63653 - The computer account password must not be prevented from being reset.
[US]STIG V-3373 - The maximum age for machine account passwords is not set to requirements.
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

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. Stale user accounts are a significant security issue, as former employees and external attackers could use those accounts to attack the organization.

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 –AccountInActive –UsersOnly –TimeSpan 180:00:00:00 –ResultPageSize 2000 –ResultSetSize $null | ?{$_.Enabled –eq $True} | Select-Object Name, SamAccountName, DistinguishedName.

Points:

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

Documentation:

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

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 –AccountInActive –ComputersOnly –TimeSpan 180:00:00:00 –ResultPageSize 2000 –ResultSetSize $null | ?{$_.Enabled –eq $True} | Select-Object Name, SamAccountName, DistinguishedName.

Points:

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

Documentation:

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

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

Documentation:

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

Verify if there are restrictions for internet connectivity of script engines

Rule ID:

S-FirewallScript

Description:

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

Technical Explanation:

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

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

Advised Solution:

1) Create Firewall Rules via GPO

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

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

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

Introduced in:

3.3.0.0

Points:

Informative rule (0 point)

Documentation:

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

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:

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

Check for hidden group membership for user accounts

Rule ID:

S-PrimaryGroup

Description:

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

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".
You can use the following script to list Users with a primary group id different from domain users:
$DomainUsersSid = New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::AccountDomainUsersSid,(Get-ADDomain).DomainSID)

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

Points:

15 points if present

Documentation:

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

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

Documentation:

[FR]ANSSI - Accounts with passwords stored using reversible encryption (vuln3_reversible_password)3
[MITRE]T1110.002 Brute Force: Password Cracking

Check for reversible passwords 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 a DCSync attack

Advised Solution:

To remove this risk, there should be no account(s) with reversible encryption for the password. 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

Documentation:

[FR]ANSSI - Accounts with passwords stored using reversible encryption (vuln3_reversible_password)3
[MITRE]T1110.002 Brute Force: Password Cracking

Check if all accounts require Kerberos pre-authentication

Rule ID:

S-NoPreAuth

Description:

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

Technical Explanation:

Without Kerberos pre-authentication, an attacker can request Kerberos data from the domain controller and use this data to crack the account password. You can find which accounts don't require Kerberos pre-authentication with the PowerShell command: Get-ADObject -LDAPFilter "(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 don't have the Account tab, you have to manually edit the attribute useraccountcontrol. Subtract 4194304 the value of the attribute.

Points:

5 points if present

Documentation:

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

Check if all admin accounts require Kerberos pre-authentication

Rule ID:

S-NoPreAuthAdmin

Description:

The purpose is to ensure that all admin accounts require 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 don't have the Account tab, you have to manually edit the attribute useraccountcontrol. Subtract 4194304 from the value of the attribute.

Introduced in:

2.9.0.0

Points:

5 points per discovery

Documentation:

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

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

Rule ID:

S-DefaultOUChanged

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

3.1.0.0

Points:

Informative rule (0 point)

Documentation:

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/5a00c890-6be5-4575-93c4-8bf8be0ca8d8
https://rickardnobel.se/verify-redirected-computers-container-in-active-directory/
[MITRE]Mitre Att&ck - Mitigation - User Account Management

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

Check that there is no account with never-expiring passwords

Rule ID:

S-PwdNeverExpires

Description:

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

Technical Explanation:

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

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

1 points if present

Documentation:

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

Ensure that clients support Kerberos armoring when the domain functional level is at least Windows Server 2012

Rule ID:

S-KerberosArmoring

Description:

The purpose is to ensure that clients support Kerberos armoring when domain functional level is at least Windows Server 2012

Technical Explanation:

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

Advised Solution:

To enable Kerberos armoring for client, edit the GPO and go to Computer Configuration > Administrative Templates > System > Kerberos
then enable the policy "Kerberos client support for claims, compound authentication and Kerberos armoring".

Introduced in:

2.11.1.0

Points:

Informative rule (0 point)

Documentation:

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

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

Rule ID:

S-KerberosArmoringDC

Description:

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

Technical Explanation:

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

Advised Solution:

To enable Kerberos armoring for domain controllers, edit the GPO and go to Computer Configuration > Administrative Templates > System > KDC
then enable the policy "KDC support for claims, compound authentication and Kerberos armoring".
The policy should be set to at least "Supported".

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

Introduced in:

2.11.1.0

Points:

Informative rule (0 point)

Documentation:

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

Search for Java schema extension RFC 2713

Rule ID:

S-JavaSchema

Description:

The purpose is to ensure that there is no Java schema extension

Technical Explanation:

The Log4shell vulnerability abused the fact that log4j could load objects via a special string containing JNDI load instructions.
This load instruction refers to many protocols such as CORBA, DNS, ... but also LDAP.
This rule checks if the RFC 2713 schema extension, which allows the representation of Java objects in the AD, has been applied.
More precisely it checks if the schema contains the Java attributes javacodebase, javafactory, javaclassname, javaremotelocation or javaserializeddata.

If the attributes have been found in the schema, the program reports if one of these attributes have been found on enabled user accounts.

Advised Solution:

Unfortuntaly there can be legit cases to use these Java attributes, that's why this rule is set to "informative" only.
The recommended way to deal with this situation, is to either make sure that no objects are using these attributes, or to set the value com.sun.jndi.ldap.object.trustURLCodebase to "false" in ALL your Java code.
PingCastle is displaying the active users having these Java attributes set in the Detail section.

If you want to disable the Java extension you can proceed by setting each Java attributes to defunct.
See the following procedure on how to disable existing schema attributes: https://docs.microsoft.com/en-us/windows/win32/ad/disabling-existing-classes-and-attributes

Introduced in:

2.10.1.0

Points:

Informative rule (0 point)

Documentation:


https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
https://datatracker.ietf.org/doc/html/rfc2713
https://docs.oracle.com/cd/E19424-01/820-4813/6ng8jv82s/index.html
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

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 a SIDHistory attribute using the command: get-ADObject -ldapfilter "(sidhistory=*)" -properties sidhistory.
Each security descriptor of the domain, including file shares for example, should be reviewed to be rewritten with the new SID of the account. Then, the attribute can be removed of these accounts using the migration tool or a PowerShell snippet Remove-SIDHistory once the migration is completed.

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

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

Points:

5 points per discovery with a minimal of 15 points

Documentation:

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

Verify Terminal Services configuration best practices in GPO

Rule ID:

S-TerminalServicesGPO

Description:

This rule verifies the recommended configuration for Terminal Services.

Technical Explanation:

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

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

Advised Solution:

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

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

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

Introduced in:

3.3.0.0

Points:

Informative rule (0 point)

Documentation:

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

Verify that Defender ASR mitigations are in place

Rule ID:

S-DefenderASR

Description:

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

Technical Explanation:

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

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

Advised Solution:

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


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

Introduced in:

3.3.0.0

Points:

Informative rule (0 point)

Documentation:

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

Verify the Default Application for Script File Execution

Rule ID:

S-FolderOptions

Description:

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

Technical Explanation:

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

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

Advised Solution:

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

Introduced in:

3.3.0.0

Points:

Informative rule (0 point)

Documentation:

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

Obsolete OS

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

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

Rule ID:

S-FunctionalLevel1

Description:

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

Technical Explanation:


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

Advised Solution:

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

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

Introduced in:

2.11.2.0

Points:

5 points if present

Documentation:

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

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

Rule ID:

S-FunctionalLevel3

Description:

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

Technical Explanation:


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

Advised Solution:

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

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

Introduced in:

2.11.2.0

Points:

Informative rule (0 point)

Documentation:

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

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

Rule ID:

S-FunctionalLevel4

Description:

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

Technical Explanation:


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

Advised Solution:

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

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

Introduced in:

2.11.2.0

Points:

Informative rule (0 point)

Documentation:

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

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:

[US]STIG V-8551 - The domain functional level must be at a Windows Server version still supported by Microsoft.
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R12 [subsection.3.1]
[FR]ANSSI - DC/RODC with an obsolete operating system (vuln1_warning_dc_obsolete)1
[MITRE]Mitre Att&ck - Mitigation - Update Software

Obsolete Domain Controller (Windows Server 2003)

Rule ID:

S-DC-2003

Description:

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

Technical Explanation:

The OS Windows Server 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 Server 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:

[US]STIG V-8551 - The domain functional level must be at a Windows Server version still supported by Microsoft.
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R12 [subsection.3.1]
[FR]ANSSI - DC/RODC with an obsolete operating system (vuln1_warning_dc_obsolete)1
[MITRE]Mitre Att&ck - Mitigation - Update Software

Obsolete Domain Controller (Windows Server 2008)

Rule ID:

S-DC-2008

Description:

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

Technical Explanation:

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

Advised Solution:

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

Points:

5 points if present

Documentation:

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

Obsolete Domain Controller (Windows Server 2012)

Rule ID:

S-DC-2012

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

3.1.0.0

Points:

5 points if present

Documentation:

https://learn.microsoft.com/fr-fr/lifecycle/products/windows-server-2012-r2
[US]STIG V-8551 - The domain functional level must be at a Windows Server version still supported by Microsoft.
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R12 [subsection.3.1]
[FR]ANSSI - DC/RODC with an obsolete operating system (vuln1_warning_dc_obsolete)1
[MITRE]Mitre Att&ck - Mitigation - Update Software

Obsolete OS (Windows 10 or Windows 11)

Rule ID:

S-OS-W10

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.9.3.0

Points:

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

Documentation:

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

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 no longer supported, 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.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter {(Enabled -eq $true) -and (OperatingSystem -Like "*Server 2000*")} -Property Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion | format-table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto

Points:

40 points if present

Documentation:

[FR]ANSSI CERTFR-2005-INF-003
[MITRE]Mitre Att&ck - Mitigation - Update Software

Obsolete OS (Windows 7)

Rule ID:

S-OS-Win7

Description:

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

Technical Explanation:

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

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.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter {(Enabled -eq $true) -and (OperatingSystem -Like "*Windows 7*")} -Property Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion | format-table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto

Introduced in:

2.9.0.0

Points:

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

Documentation:

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

Obsolete OS (Windows 8)

Rule ID:

S-OS-Win8

Description:

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

Technical Explanation:

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

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.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter {(Enabled -eq $true) -and (OperatingSystem -Like "*Windows 8*")} -Property Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion | format-table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto

Introduced in:

2.10.1.0

Points:

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

Documentation:

[FR]ANSSI CERTFR-2005-INF-003
[MITRE]Mitre Att&ck - Mitigation - Update Software

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 no longer supported, 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.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter {(Enabled -eq $true) -and (OperatingSystem -Like "* NT *")} -Property Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion | format-table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto

Points:

60 points if present

Documentation:

[FR]ANSSI CERTFR-2005-INF-003
[MITRE]Mitre Att&ck - Mitigation - Update Software

Obsolete OS (Windows Server 2003)

Rule ID:

S-OS-2003

Description:

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

Technical Explanation:

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

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.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter {(Enabled -eq $true) -and (OperatingSystem -Like "*Server 2003*")} -Property Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion | format-table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto

Points:

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

Documentation:

[FR]ANSSI CERTFR-2005-INF-003
[MITRE]Mitre Att&ck - Mitigation - Update Software

Obsolete OS (Windows Server 2008)

Rule ID:

S-OS-2008

Description:

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

Technical Explanation:

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

Advised Solution:

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

Points:

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

Documentation:

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

Obsolete OS (Windows Server 2012)

Rule ID:

S-OS-2012

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

3.1.0.0

Points:

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

Documentation:

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

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 no longer supported, 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.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter {(Enabled -eq $true) -and (OperatingSystem -Like "*Windows Vista*")} -Property Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion | format-table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto

Introduced in:

2.8.0.0

Points:

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

Documentation:

[FR]ANSSI CERTFR-2005-INF-003
[MITRE]Mitre Att&ck - Mitigation - Update Software

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 no longer supported, 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.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter {(Enabled -eq $true) -and (OperatingSystem -Like "*Windows XP*")} -Property Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion | format-table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto

Points:

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

Documentation:

[FR]ANSSI CERTFR-2005-INF-003
[MITRE]Mitre Att&ck - Mitigation - Update Software

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 the use of Kerberos on services accounts without AES support

Rule ID:

S-AesNotEnabled

Description:

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

Technical Explanation:

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

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

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

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

Advised Solution:

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

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

Introduced in:

3.3.0.0

Points:

Informative rule (0 point)

Documentation:

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

Check the use of Kerberos with weak encryption (DES algorithm)

Rule ID:

S-DesEnabled

Description:

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

Technical Explanation:

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

Advised Solution:

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

Points:

15 points if present

Documentation:

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

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 these issues before disabling SMB v1, as it will generate 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
https://docs.microsoft.com/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3
[FR]ANSSI CERTFR-2017-ACT-019
[FR]ANSSI CERTFR-2016-ACT-039
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay

Ensure that the NTLMv1 and old LM protocols are banned

Rule ID:

S-OldNtlm

Description:

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

Technical Explanation:

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

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

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

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

Advised Solution:

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

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

Introduced in:

2.11.2.0

Points:

15 points if present

Documentation:

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

Provisioning

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

Check if all DC are well registered.

Rule ID:

S-DCRegistration

Description:

The purpose is to ensure that DC are well registered.

Technical Explanation:

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

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

10 points if present

Documentation:

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

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.

If the value of the attribute ms-DS-MachineAccountQuota is not set (the program see this as "Infinite"), there is no limit to computer addition.

Note: this program checks also the GPO for SeMachineAccountPrivilege assignment. This assignment can be used to restrict the impact of the key ms-DS-MachineAccountQuota.

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 the "Authenticated Users" group in the domain controllers policy altogether. 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:

https://docs.microsoft.com/troubleshoot/windows-server/identity/default-workstation-numbers-join-domain
http://prajwaldesai.com/allow-domain-user-to-add-computer-to-domain/
http://blog.backslasher.net/preventing-users-from-adding-computers-to-a-domain.html
[MITRE]Mitre Att&ck - Mitigation - User Account Management
[FR]ANSSI - Unrestricted domain join (vuln4_user_accounts_machineaccountquota)4

Vulnerable Schema Class check

Rule ID:

S-ADRegistrationSchema

Description:

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

Technical Explanation:

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

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

Advised Solution:

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

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

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

Introduced in:

2.9.3.0

Points:

10 points if present

Documentation:


https://bugs.chromium.org/p/project-zero/issues/detail?id=2186
https://gist.github.com/IISResetMe/399a75cfccabc1a17d0cc3b5ae29f3aa#file-update-msexchstoragegroupschema-ps1
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34470
[FR]ANSSI - Schema class allowing dangerous object creation (vuln2_warning_schema_posssuperiors)2
[MITRE]Mitre Att&ck - Mitigation - User Account Management

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 check if there are duplicate accounts within the domain. A duplicate account is essentially a duplicate of two objects having the same attributes.

Technical Explanation:

To identify a duplicate account, a check is performed on the "DN" and the "sAMAccountName". When a DC detects a conflict, there is a replacement performed on the second object.

Advised Solution:

Duplicate accounts being present often means there are process failures, and they should be identified and removed. To identify all duplicate accounts, you can use the following PowerShell commands: get-adobject -ldapfilter "(cn=*cnf:*)" ; get-adobject -ldapfilter "(sAMAccountName=$duplicate)"

Points:

5 points if present

Documentation:

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

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 November, 18th 2014. 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 patch 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
[FR]ANSSI CERTFR-2014-ALE-011
[MITRE]Mitre Att&ck - Mitigation - Update Software

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 March, 14th 2017. 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 patch 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 program from github 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
[FR]ANSSI CERTFR-2017-ALE-010
[MITRE]Mitre Att&ck - Mitigation - Update Software

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 been patched as well in these 6 months

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:

[MITRE]Mitre Att&ck - Mitigation - Update Software

Search for WSUS configuration enabling the use of a user proxy

Rule ID:

S-WSUS-UserProxy

Description:

The purpose is to ensure that there is no user proxy possibility for WSUS

Technical Explanation:

Unprivileged domain users may set a user proxy that is used for Windows Update if it is being allowed by a GPO.
Since the cumulative updates from September 2020 and January 2021, WSUS clients do not use the user proxy to connect to the server by default.
However, it is possible to configure a GPO setting that allows the connection via user proxy as a fallback to the system proxy.

This program consider as an anomaly if the setting SetProxyBehaviorForUpdateDetection is set, combined with a HTTP WSUS server.

Advised Solution:

The use of a user proxy needs to be disabled.
This program is looking at element named "Select the proxy behavior" defined in GPO Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Update\Specify intranet Microsoft update service location
(refers to registry key HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\SetProxyBehaviorForUpdateDetection)

Or WSUS needs to be configured with HTTPS.
See this guide for more information:
https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus#23-secure-wsus-with-the-secure-sockets-layer-protocol

Introduced in:

2.10.1.0

Points:

1 points if present

Documentation:


https://www.gosecure.net/blog/2021/11/22/gosecure-investigates-abusing-windows-server-update-services-wsus-to-enable-ntlm-relaying-attacks/
https://github.com/pimps/wsuxploit
https://github.com/GoSecure/WSuspicious
https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update#update-setproxybehaviorforupdatedetection

[MITRE]Mitre Att&ck - Mitigation - Update Software

Search for WSUS configuration using HTTP instead of HTTPS

Rule ID:

S-WSUS-HTTP

Description:

The purpose is to ensure that there is no access of WSUS server via HTTP

Technical Explanation:

WSUS is the component used on the intranet to deliver Windows updates. The recommendation of Microsoft is to use HTTPS for transport but for convenience or tests, HTTP can be configured.
The HTTP protocol can be intercepted on the network with tools such as wsuxploit or WSuspicious (see below for links) and malicious updates can be delivered.
The attacker can then take control of many assets.

Advised Solution:

WSUS needs to be configured with HTTPS.
See this guide for more information:
https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus#23-secure-wsus-with-the-secure-sockets-layer-protocol

Then all GPO which reference the HTTP path should be changed to the HTTPS path.
This program is looking at the settings defined in "Set the intranet update service for detecting updates" and "Set the alternate download server" in GPO Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Update\Specify intranet Microsoft update service location
(refers to registry key HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\WUServer and HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\UpdateServiceUrlAlternate)

Introduced in:

2.10.1.0

Points:

5 points if present

Documentation:


https://www.gosecure.net/blog/2021/11/22/gosecure-investigates-abusing-windows-server-update-services-wsus-to-enable-ntlm-relaying-attacks/
https://github.com/pimps/wsuxploit
https://github.com/GoSecure/WSuspicious
https://docs.microsoft.com/en-us/windows/deployment/update/waas-wu-settings
[MITRE]Mitre Att&ck - Mitigation - Update Software

Search for WSUS configuration where certificate pinning has been disabled

Rule ID:

S-WSUS-NoPinning

Description:

The purpose is to ensure that WSUS Certificate Pinning has not been disabled

Technical Explanation:

Even though HTTPS makes it harder for attackers to intercept WSUS responses, it it still possible with a specific configuration.
HTTPS connections may be intercepted by a proxy that signs the response again with a self-signed certificate after receiving it from the WSUS server.
The certificate can be installed in a user cert store so responses from the HTTPS proxy can still be validated.
In the cumulative update of January 2021, Microsoft implemented a certificate pinning mechanism where the certificate served by the WSUS' IIS server is installed in a system certificate store specifically for WSUS (WindowsServerUpdateServices) that an unauthenticated user cannot control.
Certificates in this store are enforced by default to mitigate HTTPS-intercepting proxy attacks but this pinning mechanism can also be disabled via GPO.

If the WSUS cert store does not contain any certificates, the pinning will not be enforced, too.

PingCastle cannot check if the certificate is present to enforce the certificate pinning, but it checks if a GPO disable this security.

Advised Solution:

Remove the setting which disables the certificate pinning for WSUS.

It is located in: Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Update\Specify intranet Microsoft update service location
This is the setting "Allow user proxy to be used as a fallback if detection using system proxy fails".

It refers to the registry key: HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\DoNotEnforceEnterpriseTLSCertPinningForUpdateDetection

Introduced in:

2.10.1.0

Points:

2 points if present

Documentation:


https://www.gosecure.net/blog/2021/11/22/gosecure-investigates-abusing-windows-server-update-services-wsus-to-enable-ntlm-relaying-attacks/
https://github.com/pimps/wsuxploit
https://github.com/GoSecure/WSuspicious
https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update#update-donotenforceenterprisetlscertpinningforupdatedetection

[MITRE]Mitre Att&ck - Mitigation - Update Software

Privileged Accounts

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 as 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" (or are members of the built-in group "Protected Users" when your domain functional level is at least Windows Server 2012 R2).

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

Points:

20 points if present

Documentation:

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

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

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

Advised Solution:

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

Introduced in:

2.7.0.0

Points:

5 points per discovery

Documentation:

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

Check if all admin passwords are changed on the field.

Rule ID:

P-AdminPwdTooOld

Description:

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

Technical Explanation:

This rule ensure that passwords of administrator are well managed.

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

10 points if present

Documentation:

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

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

Rule ID:

P-ProtectedUsers

Description:

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

Technical Explanation:

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

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

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

Documentation:

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

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

Rule ID:

P-LogonDenied

Description:

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

Technical Explanation:

A way to collect an administrator credential is to take control of a workstation or server in the unsecured tiers and expect that an administrator will connect to it.
An attack such as credential theft or Kerberos delegation is then performed.
To reduce the impact of such compromise, the best practice is to isolate components (such as admins, DC) in tiers.
Typically, a domain admin should not be allowed to connect to any workstation or lower tier server but login only to perform highly privileged operations on tier 0 systems.

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

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

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

Advised Solution:

You should add a GPO to prohibit the logon of specific groups Domain Admins and Administrators.

The setting is located in Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.
Then "Deny" logon locally and "Deny" logon through Remote Desktop Services.

Introduced in:

2.8.0.0

Points:

1 points if present

Documentation:

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

Ensure that custom Display Specifiers are stored in SYSVOL

Rule ID:

P-DisplaySpecifier

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.11.2.0

Points:

10 points if present

Documentation:

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

ACL Check

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

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

Documentation:

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

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 right 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 could be related to a compromise of the domain

Points:

5 points per discovery

Documentation:

https://technet.microsoft.com/en-us/library/ff405676.aspx
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

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 proceeds by checking a 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
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Check if the Dns Admins group is not empty

Rule ID:

P-DNSAdmin

Description:

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

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.
The "Write All Prop" access right induces the vulnerability.

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

Advised Solution:

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

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

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

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

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

Introduced in:

2.9.0.0

Points:

Informative rule (0 point)

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
[FR]ANSSI - DnsAdmins group members (vuln4_dnsadmins)4
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

Check if there is an explicit delegation on DNS servers.

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.
The "Write All Prop" access right induces the vulnerability.

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

Advised Solution:

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

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

You should remove the explicit write delegation located in the CN=MicrosoftDNS,CN=System container and do a proper delegation.
First, grant only "Read Property", "List", "List object" and "Read permssions" to CN=MicrosoftDNS,CN=System to enable access to the RPC service.
Then on each zone (the object in the tree below with the class dnsZone), grant "Read Property", "List", "List object", "Read permissions", "Create Child", "Delete Child", "Delete", "Delete Tree".



After the Patch day the key does exist.

Introduced in:

2.8.0.0

Points:

Informative rule (0 point)

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
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40469
https://blog.0patch.com/2021/11/micropatch-for-remote-code-execution-by.html
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

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:

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

Ensure that bogus Windows Server 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 Server 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://itpro-tips.com/wp-content/uploads/files/TechnetGallery/Enterprise-Key-Admins-720eb270.zip
https://secureidentity.se/adprep-bug-in-windows-server-2016/
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
[FR]ANSSI - Bad Active Directory versions (vuln2_adupdate_bad)2
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[MITRE]T111 Two-Factor Authentication Interception

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 vulnerabilities by modifying domain permissions

Technical Explanation:

When Exchange is installed, a set of permissions is modified to allow a deep Windows integration. A dependency analysis has shown that the permissions, that Exchange has set, introduced a possibility for privilege escalation.
The most basic exploitation is that a member of the group Exchange Windows Permissions can modify 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 retrieves 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, including domain admins.

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
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

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/
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

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

Rule ID:

P-DelegationFileDeployed

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.7.0.0

Points:

5 points per discovery

Documentation:

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

Ensure that 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:

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

Ensure that 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 lose control of the domain after a permission change or to introduce a weakness in the permissions.
It proceeds 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
[FR]ANSSI - Dangerous dsHeuristics settings (vuln1_dsheuristics_bad)1
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

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 insecure backup media or perform a local privilege escalation to become the DC admin and thus the AD admin.
Local logon requires usually physical interaction, which explains why network seggregation is a best practice, but this can be bypassed. Indeed, VNC or remote server management software is a way to perform local logon remotely.
In addition, remote server management software have been the subject of many vulnerabilites, some of them can be exploited even if this software is disabled.

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
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

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 GPOs 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
[US]STIG V-1159 - The Recovery Console option is set to permit automatic logon to the system.
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

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 all Administrator Accounts in the AD are 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 than or equals than 30
then 20 points if the occurence is greater than or equals than 15

Documentation:

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

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 serves as the primary administrative account and often shares its password with the Directory Services Restore Mode password. This shared password presents a potential security vulnerability as it can be exploited to gain control of the domain, even if the account itself is disabled. This vulnerability is particularly notable in the context of a DCSync attack.

Previously, the last login date was obtained by querying the LastLogonTimestamp LDAP attribute from the Active Directory. However, there was an exception in place, allowing for a 35-day window to prevent this rule from being triggered during domain creation. Since the release of PingCastle version 3.2, the last login date is acquired by connecting to each domain controller and querying the LastLogon attribute.

Advised Solution:

To mitigate security risks effectively, it is advisable to reserve the Native Administrator account solely for emergency situations, with daily tasks being carried out using separate accounts. It is strongly recommended not to employ this account routinely, opting instead for individualized accounts for administrators and dedicated accounts for services. It's worth noting that any anomalies related to this practice will be automatically addressed and resolved within 35 days following the last login by a native administrator.

To monitor the most recent use of the administrator account, we recommend extracting the LastLogon attribute of the administrator account from ALL domain controllers. This task can be accomplished using tools such as ADSIEdit or ADExplorer. Subsequently, for each domain controller, extract the event ID 4624 corresponding to the LastLogon date. This will enable you to pinpoint the computer and process responsible for the logon event.

It's worth mentioning that prior to version 3.2 of PingCastle, this information was obtained through the LastLogonTimestamp attribute, which could have been altered by the Kerberos S4u2Self mechanism. While this approach offered the advantage of gathering data from domain controllers that were otherwise inaccessible via the network, it often resulted in a high number of false positives.

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
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/ba-p/257135
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

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.
The rule is triggered if the number of cumulated privileged members is more than 50 accounts or if it represents more than 10 percent of the user accounts.
This rule is enabled only if the domain has more than 100 active users.

Points:

10 points if present

Documentation:

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R26 [subsection.3.5]
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R30 [subsubsection.3.5.7]
[FR]ANSSI - Large privileged group member count (vuln1_privileged_members)1
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

Check that the operator groups 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:

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

Control paths

Permissions granted to someone can be difficult to analyze. Hackers use this fact to chain multiple permission leaks in order to gain control of the domain.

Check if administrator accounts are email enabled.

Rule ID:

P-AdminEmailOn

Description:

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

Technical Explanation:

The recommended approach for secure administration is to implement a Tier Zero model.
In this model, low privileged actions cannot be made by highly privileged accounts such as admins.
This means that, in practice, administrators should have two separate Windows accounts: one for regular activities and one for performing privileged actions.

Advised Solution:

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

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

Introduced in:

3.1.0.0

Points:

Informative rule (0 point)

Documentation:

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

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

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 user groups Anonymous, Everyone, Authenticated Users, Domain Users, Domain Computers and Builtin.

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
[MITRE]T1069.002 Permission Groups Discovery: Domain Groups

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

Rule ID:

P-ControlPathIndirectMany

Description:

The purpose is to check if users can abuse their write access to obtain additional privileges.

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.

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 than or equals than 200
then 15 points if the occurence is greater than or equals than 100
then 10 points if the occurence is greater than or equals than 50
then 5 points if the occurence is greater than or equals than 20

Documentation:

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

Delegation Check

Delegations are very complex to understand and may grant more privileges than initially thought.

A Delegation is granted to Everyone

Rule ID:

P-DelegationEveryone

Description:

The purpose is to verify that there is no delegation granted to "Everyone" or 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:

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

Check delegations for the recipient's existence

Rule ID:

P-UnkownDelegation

Description:

The purpose is to verify that each delegation is 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:

[US]STIG V-2370 - The access control permissions for the directory service site group policy must be configured to use the required access permissions.
[MITRE]T1187 Forced Authentication
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

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

Rule ID:

P-DelegationDCt2a4d

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

25 points per discovery

Documentation:

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

Check if all DC have no constrained delegation.

Rule ID:

P-DelegationDCa2d2

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

25 points per discovery

Documentation:

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

Check if all DC have no resource based constrained delegation.

Rule ID:

P-DelegationDCsourcedeleg

Description:

The purpose is to ensure that no resource based constrained delegations are applied to DC

Technical Explanation:

Resource based constrained delegation are a new feature of Windows Server 2012 which tries to handle the limitation of Constrained delegations.
This delegation is defined by setting the msDS-AllowedToDelegateToattribute attribute either using the GUI or a PowerShell command.

Advised Solution:

You should edit the msDS-AllowedToDelegateToattribute attribute of the domain controllers and remove the account involved.
You can do this with the PowerShell command:
Set-ADComputer COMPUTER -PrincipalsAllowedToDelegateToAccount $Null

Introduced in:

2.9.0.0

Points:

25 points per discovery

Documentation:

https://blog.stealthbits.com/resource-based-constrained-delegation-abuse/
[FR]ANSSI - Resource-based constrained delegation on domain controlers (vuln1_delegation_sourcedeleg)1
[MITRE]T1187 Forced Authentication
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Ensure that no accounts are subject to unconstrained delegation

Rule ID:

P-UnconstrainedDelegation

Description:

The purpose is to ensure that 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
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
[FR]ANSSI - Unconstrained authentication delegation (vuln2_delegation_t4d)2
[MITRE]T1187 Forced Authentication
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Irreversible change

Most of the changes can be reversed. Some not, and it can break 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 remove this group membership.

Advised Solution:

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

Points:

10 points if present

Documentation:

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

Check if OUs and Containers are protected from accidental deletion.

Rule ID:

P-UnprotectedOU

Description:

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

Technical Explanation:

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

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

Advised Solution:

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

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

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

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

Introduced in:

3.1.0.0

Points:

Informative rule (0 point)

Documentation:

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

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 Server 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 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target 'test.mysmartlogon.com'

Introduced in:

2.7.0.0

Points:

10 points if present

Documentation:

https://enterinit.com/powershell-enable-active-directory-recycle-bin
[MITRE]Mitre Att&ck - Mitigation - Audit

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 (aka accounts with never expiring password) are domain administrators

Rule ID:

P-ServiceDomainAdmin

Description:

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

Technical Explanation:

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

Advised Solution:

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

Points:

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

Documentation:

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

Check if there is the privilege "Access Credential Manager" has been explicitly granted to a user other than the "Winlogon service".

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.

A POC to exploit this privilege is available in the documents linked below.

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://github.com/daem0nc0re/PrivFu#privilegedoperations
https://github.com/daem0nc0re/PrivFu/blob/main/PrivilegedOperations/SeTrustedCredManAccessPrivilegePoC/SeTrustedCredManAccessPrivilegePoC.cs
[US]STIG V-63843 - The Access Credential Manager as a trusted caller user right must not be assigned to any groups or accounts
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

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 allows any user to act as SYSTEM.
SeDebugPrivilege is the privilege used to debug program and to access any program's memory. It can be used to create a new process and set the parent process to a privileged one.
SeRestorePrivilege can be used to modify a service running as local system and startable by all users to a chosen one.
SeBackupPrivilege can be used to backup Windows registry and use third party tools for extracting local NTLM hashes.
SeTakeOwnershipPrivilege can be used to take ownership of any secureable object in the system including a service registry key. Then to change its ACL to define its own service running as LocalSystem.
SeCreateTokenPrivilege can be used to create a custom token with all privileges and thus be abused like SeTcbPrivilege
SeImpersonatePrivilege and SeAssignPrimaryTokenPrivilege can be abused to impersonate privileged tokens. These tokens can be retrieved by establishing security context such as Local DCOM DCE/RPC reflection.
SeSecurityPrivilege can be used to clear the Windows Security Event Log and shrink it to make events flushed soon. Also read security log and view events where the user inverted the login and its password.
SeManageVolumePrivilege can be used to reset the security descriptor on the C volume and thus, change the inherited permissions to critical files

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
https://twitter.com/0gtweet/status/1303427935647531018?s=20
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Read-Only Domain Controllers

Read-Only Domain Controllers are used in poor physically secured zones. An incorrect protection level can leak sensitive data.

Check if a privileged group can be revealed on a RODC

Rule ID:

P-RODCRevealOnDemand

Description:

The purpose is to ensure that no privileged group can be revealed on RODC

Technical Explanation:

There is an attribute on each RODC which enumerates the groups that the RODC can retrieve.
When the RODC retrieve the user account, all secrets are integrated into the data, meaning that the RODC can impersonate the user account.
In this case, a user or a group has been identified that have a RID (the last part of the SID) lower than 1000.
All privileged groups have a RID lower than 1000, than means that the RODC can get access at any time to that privileged information.

Advised Solution:

Edit the attribute msDS-RevealOnDemandGroup and remove the privileged user or group identified.

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

Introduced in:

2.9.0.0

Points:

5 points if present

Documentation:

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

Check if privileged users have been revealed on RODC

Rule ID:

P-RODCAdminRevealed

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

5 points per discovery

Documentation:

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

Check if RODCs have write access to the SYSVOL volume

Rule ID:

P-RODCSYSVOLWrite

Description:

The purpose is to ensure that no RODC has write access to the SYSVOL

Technical Explanation:

The SYSVOL Volume is a special DFS volume used to store system files such as GPO.
Read Only Domain Controllers (RODC) have read-only access to it.
If it has write access, it can change the file locally and propagate them to all writable domain controllers.
And thus enable an attacker to take control of the domain by modifying a GPO applied to Domain Controllers.

Advised Solution:

Locate the domain controller object related to the RODC in ADSIEdit.
Then zoom on CN=DFSR-LocalSettings then CN=Domain System Volume.
Edit the attribute msDFSR-ReadOnly and change it from false to true.

Introduced in:

2.9.0.0

Points:

5 points per discovery

Documentation:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-frs2/3588b343-4076-4776-b5c0-78e2b3d91ed3
[MITRE]T1207 Rogue Domain Controller
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Check if the protection against revealing privileged group is active

Rule ID:

P-RODCNeverReveal

Description:

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

Technical Explanation:

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

Advised Solution:

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

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

Introduced in:

2.9.0.0

Points:

5 points if present

Documentation:

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

Check the Allowed RODC Password Replication Group group

Rule ID:

P-RODCAllowedGroup

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

5 points if present

Documentation:

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

Check the Denied RODC Password Replication Group group

Rule ID:

P-RODCDeniedGroup

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

5 points if present

Documentation:

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

Krbtgt accounts created for RODC not associated anymore to a RODC

Rule ID:

P-RODCKrbtgtOrphan

Description:

The objective is to assess if krbtgt accounts created for RODC are still associated to a RODC.

Technical Explanation:

Kerberos tickets are digitally signed data structures, authenticated by the hash of the well-known krbtgt password.
To establish a lower trust level, Read-Only Domain Controllers (RODCs) utilize a unique krbtgt account.
This account is identifiable by its name, which follows the format ‘krbtgt_XXXX’, where ‘XXXX’ represents a numeric sequence.
Ideally, when an RODC is decommissioned, its corresponding krbtgt account should also be deleted.
However, this does not always occur as expected.
PingCastle is searching these accounts by looking at user objects, starting with krbtgt_ and whose attribute msDS-KrbTgtLinkBl is empty but whose attribute msDS-SecondaryKrbTgtNumber is not empty.
Note: the special account krbtgt_AzureAD should not be returned by this search

Advised Solution:

Firstly, identify the associated Read-Only Domain Controller (RODC) and ensure it has been decommissioned.
Note that the user executing the scan might not have the necessary permissions to view the RODC.
You can utilize the following command to list all RODCs: Get-ADDomainController -Filter {IsReadOnly -eq $true}

Following this, proceed to delete the associated krbtgt account.
Disabling the account will not suffice, as all krbtgt accounts are inherently disabled, serving solely as repositories for encryption material.
Please be aware that once removed, this action cannot be undone.

Introduced in:

3.3.0.0

Points:

1 points if present

Documentation:

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/mailbag-rodcs-krbtgt-orphans-and-load-balancing-rodc-connection/ba-p/256064
https://specterops.io/blog/2023/01/25/at-the-edge-of-tier-zero-the-curious-case-of-the-rodc/
[FR]ANSSI - Orphan RODC krbtgt accounts (vuln3_rodc_orphan_krbtgt)3
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

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 trust

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

Check if AES is enabled on trusts

Rule ID:

T-AlgsAES

Description:

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

Technical Explanation:

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

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

Advised Solution:

Enable AES on the domain.

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

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

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

Introduced in:

2.11.0.0

Points:

1 points if present

Documentation:

https://techcommunity.microsoft.com/t5/itops-talk-blog/tough-questions-answered-can-i-disable-rc4-etype-for-kerberos-on/ba-p/382718
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/6cfc7b50-11ed-4b4d-846d-6f08f0812919
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

SID Filtering

Isolation of domains is critical to avoid a global compromise.

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 used to propagate a compromise through trusts. SID Filtering for domain-to-domain trust is called a quarantine and is disabled by default. SID Filtering to a forest is enabled by default and disabling it is called "enabling SID History".

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

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

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 than or equals than 4
then 80 points if the occurence is greater than or equals than 2
then 50 points if present

Documentation:

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

SIDHistory

When doing migrations, a double identity may be attributed. It can have side effects up to the compromise 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.

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

Points:

50 points if present

Documentation:

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

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-$$$, for example 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 (sAMAccountName=*$$$)

Points:

5 points if present

Documentation:

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

Check if dangerous SID are stored in the SIDHistory attribute.

Rule ID:

T-SIDHistoryDangerous

Description:

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

Technical Explanation:

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

Advised Solution:


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

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

Introduced in:

2.9.0.0

Points:

10 points if present

Documentation:

https://support.microsoft.com/en-us/help/243330/well-known-security-identifiers-in-windows-operating-systems
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]
[FR]ANSSI - Accounts or groups with unexpected SID history (vuln2_sidhistory_dangerous)2
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection

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. Possibly hacking tools such as mimikatz could be used to undo a deletion with for example the lsadump::dcshadow attack.

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

Points:

10 points per discovery

Documentation:

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

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 (Applications 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 compromised 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

Documentation:

[MITRE]T1210 Exploitation of Remote Services

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 Print 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 recommendations 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
[FR]ANSSI - Inbound trust relationships with delegation (vuln3_trusts_tgt_deleg)3
[MITRE]T1187 Forced Authentication
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

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

Documentation:

[MITRE]T1210 Exploitation of Remote Services

Trust inactive

Any trust introduces 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 been 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. Otherwise, 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
[FR]ANSSI - Trust account passwords unchanged for more than a year (vuln2_trusts_accounts)2
[MITRE]T1557 Man-in-the-Middle

Trust with Azure

The link with Azure Systems may create new compromise methods between the cloud and on-premise systems.

Check if password rotation is in place with AzureAD SSO

Rule ID:

T-AzureADSSO

Description:

The purpose is to check that password rotation is in place with Azure AD SSO

Technical Explanation:

AzureAD SSO is performed using a gateway. This gateway converts a Kerberos TGS ticket to a SAML ticket.
In short, a connection is made to the computer account AZUREADSSOACC and the secret of this user account is used as a shared secret with AzureAD.
Despite the fact that this computer account should have its password automatically changed every 30 days, it did not happen.
That means that an extraction of its password (using DCSync for example) can lead to an AzureAD compromise.

Advised Solution:

Run the script referenced in the documentation below to change the password of the account AZUREADSSOACC.

Points:

20 points if present

Documentation:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-faq#how-can-i-roll-over-the-kerberos-decryption-key-of-the-azureadssoacc-computer-account
https://itpro-tips.com/wp-content/uploads/files/TechnetGallery/Azure-AD-SSO-Key-Rollover-d2f1604a.zip
https://www.dsinternals.com/en/impersonating-office-365-users-mimikatz/
[FR]ANSSI - Trust account passwords unchanged for more than a year (vuln2_trusts_accounts)2
[MITRE]T1003 OS Credential Dumping

Anomalies

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

Audit

The default audit policy of Windows does not collect key events to trace activities or discover past compromise.

Check if PowerShell logging is 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
[US]STIG V-68819 - PowerShell script block logging must be enabled
[MITRE]Mitre Att&ck - Mitigation - Audit

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

Identify the Audit settings to apply and fix them.
Be aware that there are two places for audit settings.
For "Simple" audit configuration:
in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Audit Policies
For "Advanced" audit configuration:
in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration
Also be sure that the audit GPO is applied to all domain controllers, as the underlying object may be in a OU where the GPO is not applied.

Introduced in:

2.8.0.0

Points:

10 points if present

Documentation:

https://adsecurity.org/?p=3299
https://adsecurity.org/?p=3377
[MITRE]Mitre Att&ck - Mitigation - Audit

Backup

Although 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 to check if the backups are actually up to date in case they are needed. The alert can be triggered when a domain is backed up using non-recommended methods

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 than or equals than 7

Documentation:

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

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
[MITRE]Mitre Att&ck - Mitigation - Data Backup

Certificate take over

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

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

Rule ID:

A-WeakRSARootCert2

Description:

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

Technical Explanation:

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

Advised Solution:

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

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

Introduced in:

2.9.0.0

Points:

1 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
https://www.ssi.gouv.fr/guide/cryptographie-les-regles-du-rgs/
[US]STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).
[FR]ANSSI - Weak or vulnerable certificates (vuln3_certificates_vuln)3
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space

Check for Certificates using a weak RSA exponent

Rule ID:

A-CertWeakRsaComponent

Description:

The purpose is to ensure that there is no use of a certificate with a weak RSA exponent

Technical Explanation:

The RSA public key is composed of two parts: The modulus and the exponent. The exponent must be a prime number and its value is usually 65537.
It is not recommended to have a exponent larger than 65537 for compatibility reasons as for example older Windows handle the exponent in 4 bytes.
Having a lower exponent, such as 3, gives a significant performance boost (up to 8 times), but it is considered less secure.

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

5 points if present

Documentation:

[FR]ANSSI - Weak or vulnerable certificates (vuln3_certificates_vuln)3
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space

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 unsafe

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
https://www.ssi.gouv.fr/guide/cryptographie-les-regles-du-rgs/
[US]STIG V-14820 - PKI certificates (server and clients) must be issued by the DoD PKI or an approved External Certificate Authority (ECA).
[FR]ANSSI - Weak or vulnerable certificates (vuln1_certificates_vuln)1
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space

Check for Certificates using the DSA algorithm for signature

Rule ID:

A-CertWeakDSA

Description:

The purpose is to ensure that there is no use of a certificate using a DSA key for signature

Technical Explanation:

Digital Signature Algorithm (DSA), is a NIST standard signature algorithm, part of the 1993 Digital Signature Standard(FIPS 186). The proposed FIPS 186-5 draft deprecates the use of DSA and will forbid its usage for digital signature purposes.
The annex E of FIPS 186-5 specifies: DSA is no longer approved for digital signature generation. DSA may be used to verify signatures generated prior to the implementation date of this standard.

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

Informative rule (0 point)

Documentation:

https://csrc.nist.gov/publications/detail/fips/186/5/draft
[FR]ANSSI - Weak or vulnerable certificates (vuln1_certificates_vuln)1
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space

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 deprecated MD2 hashing algorithm in Intermediate Certificate

Technical Explanation:

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

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 deprecated MD4 hashing algorithm in Intermediate Certificate

Technical Explanation:

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

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 deprecated MD5 hashing algorithm in Intermediate Certificate

Technical Explanation:

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

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

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

Check for Root Certificates using unsafe hashing algorithm (MD2)

Rule ID:

A-MD2RootCert

Description:

The purpose is to ensure that no Root Certificates use the deprecated MD2 hashing algorithm

Technical Explanation:

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

Check for Root Certificates using unsafe hashing algorithm (MD4)

Rule ID:

A-MD4RootCert

Description:

The purpose is to ensure that no Root Certificates use the deprecated MD4 hashing algorithm

Technical Explanation:

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

Check for Root Certificates using unsafe hashing algorithm (MD5)

Rule ID:

A-MD5RootCert

Description:

The purpose is to ensure that no Root Certificates use the deprecated MD5 hashing algorithm

Technical Explanation:

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

Check for Root Certificates using unsafe hashing algorithm (SHA0)

Rule ID:

A-SHA0RootCert

Description:

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

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

Check for Root Certificates using unsafe hashing algorithm (SHA1)

Rule ID:

A-SHA1RootCert

Description:

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

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

Check for the ROCA vulnerability in certificates

Rule ID:

A-CertROCA

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

15 points if present

Documentation:

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

Check if authentication certificate templates allow users to control the subject

Rule ID:

A-CertTempCustomSubject

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.9.3.0

Points:

15 points if present

Documentation:

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

Check if authentication certificate templates disallow the tracking of the certificate requester

Rule ID:

A-CertTempNoSecurity

Description:

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

Technical Explanation:

Certificate requests are tracked by UPN and dnsHost name for computers.
Usually, editing dnsHost change the value of the attribute servicePrincipalName and duplications are prohibited.
But there is no constraint on the dnsHost attribute and a controlled change of this attribute (without changing the SPN) can lead to duplicates.
An attacker can then change the DNS of a compromise host to the DC DNS and request a certificate on behalf the DC, thus impersonating it and controlling the domain.

Advised Solution:

Edit the certificate template object and specifically the attribute msPKI-Enrollment-Flag.
Unset the flag CT_FLAG_NO_SECURITY_EXTENSION (0x80000) aka substract the value 524288 from the attribute msPKI-Enrollment-Flag.

Introduced in:

2.11.0.0

Points:

15 points if present

Documentation:

https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26931
[FR]ANSSI - Dangerous enrollment permission on authentication certificate templates (vuln1_adcs_template_auth_enroll_with_name)1
[MITRE]T1558 Steal or Forge Kerberos Tickets

Check if certificate enrollment can be done with HTTP

Rule ID:

A-CertEnrollHttp

Description:

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

Technical Explanation:

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

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

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

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

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

Advised Solution:

The access to certificate enrollment with HTTP should be disabled.

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

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

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

Introduced in:

2.11.0.0

Points:

5 points if present

Documentation:

https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429
https://dirkjanm.io/ntlm-relaying-to-ad-certificate-services/
https://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/
https://www.vkernel.ro/blog/installing-and-configuring-cep-and-ces-for-certificate-enrolling-on-non-domain-joined-computers
[MITRE]T1557 Man-in-the-Middle

Check if certificate templates can be edited by everyone.

Rule ID:

A-CertTempAnyone

Description:

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

Technical Explanation:

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

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

Advised Solution:

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

Introduced in:

2.9.3.0

Points:

15 points if present

Documentation:

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

Check if Extended Protection is in place for certificate requests

Rule ID:

A-CertEnrollChannelBinding

Description:

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

Technical Explanation:

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

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

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

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

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

Advised Solution:

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

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

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

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

Introduced in:

2.11.0.0

Points:

5 points if present

Documentation:

https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429
https://dirkjanm.io/ntlm-relaying-to-ad-certificate-services/
https://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/
[MITRE]T1557 Man-in-the-Middle

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 broken and it is strongly advised to disable them.
The SSL protocols in Windows is provided by the SChannel component.
The SChannel component needs to be tuned in order to not propose these weak protocols. Many guidelines to handle this problem issued by Microsoft do not talk about SChannel but rather IIS. These guidlines are quoted in the documentation section below.

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

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

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
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space

Check if LDAPS is using Tls 1.0 or Tls 1.1.

Rule ID:

A-DCLdapsProtocolAdvanced

Description:

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

Technical Explanation:

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

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

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

Advised Solution:

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

Introduced in:

3.1.0.0

Points:

Informative rule (0 point)

Documentation:

https://support.microsoft.com/en-us/topic/kb5017811-manage-transport-layer-security-tls-1-0-and-1-1-after-default-behavior-change-on-september-20-2022-e95b1b47-9c7c-4d64-9baf-610604a64c3e
https://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
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space

Check if WSUS is used with weak SSL protocol.

Rule ID:

A-WSUS-SslProtocol

Description:

The purpose is to ensure that all WSUS servers don't use weak SSL protocols.

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 SSL is exposed.
Please note that PingCastle is using the native .Net SSL stack to perform this test. .Net begins to ignore these weak protocols starting the version 4.7 of the framework and as a consequence, PingCasle may miss some weak protocol detection.

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

Advised Solution:

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

Introduced in:

2.10.1.0

Points:

5 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
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space

Check the permission of agent certificate templates

Rule ID:

A-CertTempAgent

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.9.3.0

Points:

15 points if present

Documentation:

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

Check the purpose provided by certificate templates

Rule ID:

A-CertTempAnyPurpose

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.9.3.0

Points:

15 points if present

Documentation:

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

Golden ticket

There are key secrets in Active Directory which provide seeds to the cryptographic processes. A leak could lead to a total compromise of the 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 a secret, stored as the password of the krbtgt account, to sign its tickets. If the hash of the password of the krbtgt account is retrieved, it can be used to generate authentication tickets at will.
To mitigate this attack, it is recommended to change the krbtgt password between 40 days and 6 months. If this is not the case, every backup done until the last password change of the krbtgt account can be used to emit Golden tickets, compromising the entire domain.
Retrieval of this secret is one of the highest priority in an attack, as this password is rarely changed and offer a long term backdoor.
Also this attack can be performed using the former password of the krbtgt account. That's why the krbtgt password should be changed twice to invalidate its leak.

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 10 hours between each krbtgt password change (this is the duration of a ticket life).

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

Points:

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

Documentation:

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

Local group vulnerability

The GPO deployed settings are applied to computers locally and they can be abused to take control of individual computers.

Check if a GPO assigns everyone to a local group

Rule ID:

A-MembershipEveryone

Description:

The purpose is to identify if there are local groups 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 adds local membership using a GPO.
In this case the rule triggers if one is found with "Everyone" or "Authenticated Users" or "Domain Users", ... as members.
It basically means that the local Group has no restriction on belongs to it. This represents a security risk as Local Group are supposed to have more accesses or rights.
The GPO configuration is located in Computer Configuration / Policies / Windows Settings / Security Settings / Restricted Group

This rule checks also the membership set in Computer Configuration / Preferences / Control Panel Settings / Local Users and group.

Advised Solution:

In order to correct the issue, you should edit the GPO and change the local group assignation. Another solution is to change the group to 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
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

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 very 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 a flawed 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:

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

Check if Authenticated Users can create DNS records

Rule ID:

A-DnsZoneAUCreateChild

Description:

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

Technical Explanation:

When a computer is joined to a domain, a DNS record is created in the DnsZone to allow the computer to update its DNS settings.
By design, Microsoft choose to grant to the group Authenticated Users (aka every computers and users) the right to create DNS records.
Once created, only the owner keeps the right to edit the new object.

The vulnerability is that specific DNS records can be created to perform man-in-the-middle attacks.
One example is to create a wildcard record (a record with the name "*"), a failover DNS record or anticipating the creation of a DNS record with the right permissions.

Advised Solution:

As of today, this rule is considered "informative" because the default configuration where Authenticated Users can create DNS records is considered safe.
The reason for this classification is that no exploitation of that vulnerability has been reported.

The proposed enhancement is to replace the identity who has been granted the right to create DNS Records (permission CreateChild) from Authenticated Users to Domain Computers.
To perform this change, you have to edit the permission of the DNSZone whose object is located in the container CN=MicrosoftDNS,DC=DomainDnsZones.

It should be noticed that if there is a privilege escalation on a computer, an attacker can impersonate the computer account and bypass this mitigation.

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

Introduced in:

2.10.1.0

Points:

Informative rule (0 point)

Documentation:

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

Check if DNS Zones are configured with insecure update.

Rule ID:

A-DnsZoneUpdate2

Description:

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

Technical Explanation:

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

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

1 points if present

Documentation:

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

Check if DNS Zones are configured with insecure update.

Rule ID:

A-DnsZoneUpdate1

Description:

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

Technical Explanation:

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

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

15 points if present

Documentation:

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

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 overrides 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
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay

Check if NTFRS is used to replicate SYSVOL

Rule ID:

A-NTFRSOnSysvol

Description:

The purpose is to ensure that the old NTFRS protocol is not used to replicate the SYSVOL share.

Technical Explanation:

NTFRS is an old protocol and is considered insecure.
The SYSVOL share is mainly hosted on domain controllers to host GPO files and login scripts.
If the content can be modified, it can be used to grant to a hacker the control of the computers reading these configuration files.
To know if the setting is enabled, PingCastle read the following LDAP entry: CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System
If there is any entry found, the program consider that NTFRS is in use for SYSVOL replication.

Starting in Windows Server 2019, promoting new domain controllers requires the DFS Replication (DFSR) to replicate the contents in the SYSVOL share.
As a consequence this rule become informative if at least one Windows Server 2019 or more recent is installed as a Domain Controller.

Please note that at the time of writing, Microsoft supports it until Windows Server 2022 (see the Open Specification link in the documentation section below)

Advised Solution:

You have to migrate from NTFRS to DFS replication. See the documentation below for more details.

Introduced in:

2.9.0.0

Points:

5 points if the occurence is greater than or equals than 2
then Informative rule (0 point)

Documentation:

https://docs.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr
https://support.microsoft.com/en-us/help/312862/recovering-missing-frs-objects-and-frs-attributes-in-active-directory
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-frs1/d18cc589-677e-4133-97e5-113641792c5e
https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/sysvol-dfsr-migration-fails-after-in-place-upgrade
[FR]ANSSI - SYSVOL replication through NTFRS (vuln2_sysvol_ntfrs)2
[MITRE]T1563 Remote Service Session Hijacking

Check if signing is really required for LDAP

Rule ID:

A-DCLdapSign

Description:

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

Technical Explanation:

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

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

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

Advised Solution:

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

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

Introduced in:

2.11.0.0

Points:

5 points if present

Documentation:

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

Check if the Channel Binding is enabled for LDAPS

Rule ID:

A-DCLdapsChannelBinding

Description:

The purpose is to check if the Channel Binding feature of LDAPS is enforced

Technical Explanation:

LDAPS (opposed to LDAP) does not allow message signature because this protection is made by the TLS layer.
As a consequence, forged LDAP packets can be relayed in a TLS tunnel, thus becoming LDAPS and without any protection against relay.

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

PingCastle is testing if this binding is in place by performing a LDAPS authentication with Channel Binding enabled and disabled.
False positives may exists if the PingCastle program is run on the server tested. That's why, if PingCastle is run on a DC, the DC will not be tested.

Advised Solution:

You have to make sure that ALL LDAPS clients are compatible with Channel Binding.
All supported Windows have been updated since March 2020 to take this into account and also most of the Unix clients (see the RedHat bulletin link below).

You can start auditing via registry, on each domain controller
Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2
Then monitor the Windows event IDs 3039 and 3040.

Once it has been verified that all clients are compatible, Channel Binding can be enforced:
create the key LdapEnforceChannelBinding in HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters and set its value to 1 or 2

Introduced in:

2.11.0.0

Points:

5 points if present

Documentation:

https://support.microsoft.com/en-us/topic/use-the-ldapenforcechannelbinding-registry-entry-to-make-ldap-authentication-over-ssl-tls-more-secure-e9ecfa27-5e57-8519-6ba3-d2c06b21812e
https://support.microsoft.com/en-us/topic/2020-2023-and-2024-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a
https://oxfordcomputergroup.com/resources/ldap-channel-binding-signing-requirements/
https://github.com/zyn3rgy/LdapRelayScan
https://access.redhat.com/articles/4661861
http://gary-nebbett.blogspot.com/2020/01/ldap-channel-binding.html
[MITRE]T1557 Man-in-the-Middle

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 signing enabled when communicating with domain controllers

Technical Explanation:

If SMB signing is not required on domain controllers, it can lead to several security risks and potential problems like Man-in-the-Middle (MitM) or relaying attacks like e.g. the so called RemotePotato0. An often used attack tool is Python Responder, which can be used to compromise a domain by listening for SMB connections, injecting rogue data into the communications and relaying it to a different system.
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. See the official documentation for more information.

Introduced in:

2.5.0.0

Points:

5 points if present

Documentation:

https://www.sentinelone.com/labs/relaying-potatoes-another-unexpected-privilege-escalation-vulnerability-in-windows-rpc-protocol/
https://trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022
https://msdn.microsoft.com/en-us/library/cc246675.aspx
[FR]ANSSI CERTFR-2015-ACT-021
[MITRE]T1557 Man-in-the-Middle

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 signing enforced when communicating with domain controllers

Technical Explanation:

If SMB signing is not required on domain controllers, it can lead to several security risks and potential problems like Man-in-the-Middle (MitM) or relaying attacks like e.g. the so called RemotePotato0. An often used attack tool is Python Responder, which can be used to compromise a domain by listening for SMB connections, injecting rogue data into the communications and relaying it to a different system.
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. See the official documentation for more information.

Introduced in:

2.5.0.0

Points:

Informative rule (0 point)

Documentation:

https://www.sentinelone.com/labs/relaying-potatoes-another-unexpected-privilege-escalation-vulnerability-in-windows-rpc-protocol/
https://trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022
https://msdn.microsoft.com/en-us/library/cc246675.aspx
[FR]ANSSI CERTFR-2015-ACT-021
[MITRE]T1557 Man-in-the-Middle

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 endangered by explicitly disabling LDAP signing.

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
[MITRE]T1557 Man-in-the-Middle

Hardened Paths weakness

Rule ID:

A-HardenedPaths

Description:

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

Technical Explanation:

Two vulnerabilities have been reported in 2015 (MS15-011 and MS15-014) which allows a domain takeover via GPO modifications done with a man-in-the-middle attack.
To mitigate these vulnerabilites, Microsoft has designed a workaround named "Hardened Paths". It forces connection settings to enforce Integrity, Mutual Authentication or Privacy.
By default if this policy is empty, if will enforce Integrity and Mutual Authentication on the SYSVOL or NETLOGON shares.
This rule checks if there have been any overwrite to disable this protection.

Advised Solution:

You have to edit the Hardened Path section in the GPO.
This section is located in Computer Configuration/Policies/Administrative Templates/Network/Network Provider.
Check each value reported here and make sure that entries containing SYSVOL or NETLOGON have RequireIntegrity and RequireMutualAuthentication set to 1.
In addition to that, check entries having the pattern \\DCName\* and apply the same solution.

Introduced in:

2.10.1.0

Points:

5 points if present

Documentation:


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

Pass-the-credential

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

Automatic password rotation for smart card is not in place

Rule ID:

A-SmartCardPwdRotation

Description:

The purpose is to ensure that automatic password rotation for smart card only accounts is in place

Technical Explanation:

With the introduction of a feature in Windows Server 2016, the password hash for accounts that require smart card authentication can be automatically rotated.
This is important because when smart card authentication is used, the password itself is not utilized, leading to the password hash remaining unchanged.
An unchanged password hash over an extended period increases the risk of being brute-forced.

Advised Solution:

Ensure your domain's functional level is at least Windows Server 2016 or higher.
Set the msDS-ExpirePasswordsOnSmartCardOnlyAccounts attribute to TRUE at the domain root.
This action will enable the automatic rotation of the password hash for smart card only accounts.

Introduced in:

3.3.0.0

Points:

Informative rule (0 point)

Documentation:

https://learn.microsoft.com/fr-fr/lifecycle/products/windows-server-2012-r2
[US]STIG V-72821 - All accounts, privileged and unprivileged, that require smart cards must have the underlying NT hash rotated at least every 60 days.
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R38 [paragraph.3.6.2.2]
[FR]ANSSI - Missing password expiration for smart card users (vuln4_smartcard_expire_passwords)4
[MITRE]T1110.002 Brute Force: Password Cracking

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 cards to protected sensitive accounts is a good thing. Nevertheless, when the "Smart Card required" flag is set, the password of the account is not changed anymore by default. 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 a few solutions to fix this issue, the most obvious being to change the user password on a regular basis.
The fastest way is to check if the domain has the attribute msDS-ExpirePasswordsOnSmartCardOnlyAccounts, which is available for Windows Server 2016 and later versions and handles periodically hash change.
Be sure also that functional level is at least Windows Server 2016 the GPO "Enable rolling of expiring NTLM secrets during sign on, for users who are required to use Microsoft Passport or smart card for interactive sign on" is not disabled.
Another possibility, instead of changing the password, is to disable the flag "this account requires a smart card" then re-enable it, which will trigger an internal password hash change.
You can also used the script provided by the DoD named Invoke-SmartcardHashRefresh (see link below)

Points:

30 points if present

Documentation:

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

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 the 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 use this protection, such as the Windows 7 KB2871997 patch.

Advised Solution:

The Protected Users group is automatically created when the PDC (primary DC) emulator role is transferred to Windows Server 2012 R2 or newer domain controller. The group is then automatically replicated to all other domain controllers.
Warning: Do not add service accounts 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
[US]STIG V-78131 - Accounts with domain level administrative privileges must be members of the Protected Users group in domains with a domain functional level of Windows 2012 R2 or higher.
[FR]ANSSI CERTFR-2017-ALE-012
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

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

Rule ID:

A-LAPS-Joined-Computers

Description:

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

Technical Explanation:

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

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

Advised Solution:

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

Introduced in:

2.9.3.0

Points:

5 points if present

Documentation:

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

Check if the LAPS tool to handle the native local administrator passwords 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 address the risk through alternative measures, you can disregard this finding. Customers using Netwrix PingCastle Pro or Enterprise versions can add this item as an exception.

Points:

15 points if present

Documentation:

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

Ensure that Domain Controllers don't deny the change of computer account passwords.

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 this GPO setting 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
[US]STIG V-4408 - The domain controller must be configured to allow reset of machine account passwords.
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Ensure that the Print Spooler service 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 Print Spooler service

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

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

Rule ID:

A-DC-WebClient

Description:

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

Technical Explanation:

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

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

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

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

Advised Solution:

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

Introduced in:

2.11.0.0

Points:

Informative rule (0 point)

Documentation:

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

RPC interfaces potentially vulnerable to Coerce attacks

Rule ID:

A-DC-Coerce

Description:

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

Technical Explanation:

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

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

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

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

Advised Solution:

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

1. Apply Group Policy Object (GPO) - "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers":
Apply this GPO specifically to the Organizational Unit (OU) "Domain Controllers".
Caution: Enabling this GPO might impact services dependent on NTLM such as files copy Backups.
Consider setting the GPO in "Audit mode" initially to identify and assess the impact on affected services.

2. Enable RPC Filters in Windows Firewall:
Configure Windows Firewall to block specific Interface IDs associated with vulnerable RPC interfaces.
This is done using the netsh command. See the documentation links for more information.
Exercise caution: This method filters the entire interface, not specific Operation Numbers (OpNum).
Adjust exceptions for necessary services to ensure critical functionality.

3. Implement External Filters (e.g., EDR, Firewalls):
Leverage third-party solutions, such as Endpoint Detection and Response (EDR) tools or firewalls.
Notable project: rpcfirewall https://github.com/zeronetworks/rpcfirewall, offering logical filtering at the OpNum level.
Be cautious of potential impact and ensure compatibility with existing infrastructure.

Introduced in:

3.1.5.1

Points:

10 points if present

Documentation:

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

Password retrieval

Passwords stored in clear text or obfuscated can be retrieved. By reusing the user's identity, an attacker's login appears like from any legitimate user. There's no need to perform a potentially detectable exploit for intrusion or lateral movement.

Check for GPO which enables 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 a DCSync attack.

Advised Solution:

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

Points:

10 points if present

Documentation:

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

Check if attributes unixUserPassword and userPassword are set

Rule ID:

A-UnixPwd

Description:

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

Technical Explanation:

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

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

Advised Solution:

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

Points:

Informative rule (0 point)

Documentation:

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

Find Password GPO

Rule ID:

A-PwdGPO

Description:

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

Technical Explanation:

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

Advised Solution:

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

Points:

20 points per discovery

Documentation:

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

Reconnaissance

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

Check for access without any account to the Name Service Provider Interface (NSPI) protocol

Rule ID:

A-DsHeuristicsAllowAnonNSPI

Description:

The purpose is to identify domains having the NSPI protocol exposed without any required 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 fAllowAnonNSPI can be set to allow access to the NSPI protocol without any account.
The NSPI protocol is used internally by Exchange to resolve addresses, and thus can be used to dump all the users of the forest. It can be exposed to the internet via RPC over HTTP.

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

5 points if present

Documentation:

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-nspi/6dd0a3ea-b4d4-4a73-a857-add03a89a543
[US]STIG V-8555 - Anonymous Access to AD forest data above the rootDSE level must be disabled.
[FR]ANSSI - Dangerous dsHeuristics settings (vuln1_dsheuristics_bad)1
[MITRE]T1110.003 Brute Force: Password Spraying

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 Linux 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
[US]STIG V-8555 - Anonymous Access to AD forest data above the rootDSE level must be disabled.
[FR]ANSSI - Dangerous dsHeuristics settings (vuln2_dsheuristics_bad)2
[MITRE]T1110.003 Brute Force: Password Spraying

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 Linux 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
[US]STIG V-14798 - Directory data (outside the root DSE) of a non-public directory must be configured to prevent anonymous access.
[MITRE]T1110.003 Brute Force: Password Spraying

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 Server 2003 DC is promoted, a pre-Windows 2000 compatibility setting can be enabled through the wizard. If it is enabled, the wizard will add "Everyone" and "Anonymous" to the pre-Windows 2000 compatible access group, and by doing so, it will authorize the domain to be queried without an account (null session)
It is possible to verify the results provided by the PingCastle solution by using a Kali distribution. You should run [rpcclient -U " target_ip_address] and press enter at the password prompt to finally type [enumdomusers].

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.
Note: removing the group "Authenticated Users" (and not keep it like advised here) is an advanced recommendation quoted in the rule A-PreWin2000AuthenticatedUsers

Points:

5 points if present

Documentation:

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

Check if DNS Zones are configured with Zone Transfers.

Rule ID:

A-DnsZoneTransfert

Description:

The purpose is to ensure that no DNS Zones are configured with Zone Transfers.

Technical Explanation:

When the Zone Transfers mechanism is enabled, an attacker can retrieve all DNS records anonymously.
He can then use this feature to generate network noise to trigger a man in the middle attack and capture credentials.

This setting is domain wide, meaning that all servers share the same setting.
Please note that PingCastle does this check to only one DNS Server of the zone.

To test if the Zone Transfers is enabled, issue the following command:
on Linux:

host -t axfr domain.name dns-server
or
dig axfr @dns-server domain.name

on Windows:
nslookup
then
server dns-server
then
set type=any
then
ls -d domain.name

Advised Solution:

You have to disable Zone Transfers.
Identify the faulty zone in the details below.
Go to the DNS console and select a zone in the "Forward Lookup Zones".
Right click on it and switch to the "Zone Transfers" tab.
Then ensure "Allow zone transfers" is not enabled "To any server".
You can also run: dnscmd /zoneresetsecondaries zone /noxfr

Introduced in:

2.9.3.0

Points:

5 points if present

Documentation:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/f97756c9-3783-428b-9451-b376f877319a
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/dnscmd
[MITRE]T1018 Remote System Discovery

Check if NetCease has been put in place to mitigate Bloodhound

Rule ID:

A-NoNetSessionHardening

Description:

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

Technical Explanation:

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

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

Informative rule (0 point)

Documentation:

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

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

Rule ID:

A-DsHeuristicsLDAPSecurity

Description:

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

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 LDAPAddAutZVerifications and LDAPOwnerModify can be set to modify the mitigatation of CVE-2021-42291.
The KB5008383 has introduced changes to default security descriptor of Computer containers to add audit and limit computer creation without being admin.
Indeed, it is recommended to not let anyone create computer accounts as they can be used to abuse Kerberos or to perform relay attacks.

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

Advised Solution:

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

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

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

Introduced in:

2.10.1.0

Points:

Informative rule (0 point)

Documentation:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5
https://support.microsoft.com/en-au/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1
[FR]ANSSI - Dangerous dsHeuristics settings (vuln3_dsheuristics_bad)3
[MITRE]T1187 Forced Authentication

Check if the UPN and SPN uniqueness check has been disabled

Rule ID:

A-DsHeuristicsDoNotVerifyUniqueness

Description:

The purpose is to identify domains having the SPN and UPN uniqueness check disabled

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 DoNotVerifyUPNAndOrSPNUniqueness can be set to disable the UPN or SPN check.
This setting has been introduced to overwrite the mitigation of the vulnerability CVE-2021-42282 fixed by the KB5008382.

Advised Solution:

The easiest and fastest way to correct this issue is to replace the 21th character of the DsHeuristics attribute. If it is not a 0, replace by 0 to fix the issue.

Introduced in:

2.10.1.0

Points:

5 points if present

Documentation:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5
https://support.microsoft.com/en-us/topic/kb5008382-verification-of-uniqueness-for-user-principal-name-service-principal-name-and-the-service-principal-name-alias-cve-2021-42282-4651b175-290c-4e59-8fcb-e4e5cd0cdb29
[FR]ANSSI - Dangerous dsHeuristics settings (vuln2_dsheuristics_bad)2
[MITRE]T1187 Forced Authentication

Check that the "Pre-Windows 2000 Compatible Access" group does not contain "Authenticated Users"

Rule ID:

A-PreWin2000AuthenticatedUsers

Description:

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

Technical Explanation:

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

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

Advised Solution:

Remove "Authenticated Users" from the PreWin2000 group.

Introduced in:

2.9.3.0

Points:

Informative rule (0 point)

Documentation:

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

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

Rule ID:

A-PreWin2000Other

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

2.9.0.0

Points:

2 points if present

Documentation:

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

Ensure that the rootDse Anonymous Binding is disabled

Rule ID:

A-RootDseAnonBinding

Description:

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

Technical Explanation:

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

Advised Solution:

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

Introduced in:

3.3.0.0

Points:

Informative rule (0 point)

Documentation:

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

Retrieve data from the domain without any account

Rule ID:

A-NullSession

Description:

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

Technical Explanation:

Unlike other rules, which check for known cause of anonymous access, this rule tries to enumerate accounts from the domain without any account. The program uses two methods: MS-SAMR with a NULL connection and MS-LSAT, which forces SID resolution with a well known SID.
NULL sessions are deactivated by default since Windows Server 2003 and Windows XP. For compatibility reasons a setting enabling them may be still active years after.
It is possible to verify the results provided by the PingCastle solution by using a Kali distribution. You should run [rpcclient -U " target_ip_address] and press enter at the password prompt to finally type [enumdomusers].

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
[US]STIG V-14798 - Directory data (outside the root DSE) of a non-public directory must be configured to prevent anonymous access.
[MITRE]T1110.003 Brute Force: Password Spraying

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 are 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 than or equals than 50
then 45 points if the occurence is greater than or equals than 45
then 40 points if the occurence is greater than or equals than 40
then 35 points if the occurence is greater than or equals than 35
then 30 points if the occurence is greater than or equals than 30
then 25 points if the occurence is greater than or equals than 25
then 20 points if the occurence is greater than or equals than 20
then 15 points if present

Documentation:

https://msdn.microsoft.com/en-us/library/ms675212(v=vs.85).aspx
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R40 [paragraph.3.6.3.1]
[FR]ANSSI - Privileged groups members having an adminCount attribute which is null or 0 (vuln2_privileged_members_no_admincount)2
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

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
[MITRE]T1110.003 Brute Force: Password Spraying

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 represent a high risk because they can fairly easily be brute-forced or password sprayed. Most CERT and agencies advise for at least 8 characters (and often this number goes up to 12)

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

Check if the guest account is enabled

Rule ID:

A-Guest

Description:

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

Technical Explanation:

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

Advised Solution:

You have to find the Guest account and disable it.

Introduced in:

2.10.1.0

Points:

15 points if present

Documentation:

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

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 of Kerberoasting attacks (offline cracking of the TGS tickets)
Note: PSO (Password Settings Objects) will be visible only if the user, which collected the information, has the permission to view it.

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

Advised Solution:

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

Points:

Informative rule (0 point)

Documentation:

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

Mitre Att&ck mapping

This is the mapping of the Mitre Att&ck framework with PingCastle rules.

Number of rules covered: 186

Number of rules not covered: 0

Techniques

Number of Mitre rules matched: 26

Number of PingCastle rules not covered: 88

Initial Access

T1078.003 Valid Accounts: Local Accounts [2]

A-Guest A-LAPS-Not-Installed

Execution

T1569 System Services [1]

P-DisplaySpecifier

Privilege Escalation

T1134.005 Access Token Manipulation: SID-History Injection [5]

S-SIDHistory T-SIDFiltering T-SIDHistoryDangerous T-SIDHistorySameDomain T-SIDHistoryUnknownDomain

Defense Evasion

T1207 Rogue Domain Controller [2]

P-RODCSYSVOLWrite S-DCRegistration

T1600.001 Weaken Encryption: Reduce Key Space [18]

A-CertROCA A-CertWeakDSA A-CertWeakRsaComponent A-DCLdapsProtocol A-DCLdapsProtocolAdvanced A-MD2IntermediateCert A-MD2RootCert A-MD4IntermediateCert A-MD4RootCert A-MD5IntermediateCert A-MD5RootCert A-SHA0IntermediateCert A-SHA0RootCert A-SHA1IntermediateCert A-SHA1RootCert A-WSUS-SslProtocol A-WeakRSARootCert A-WeakRSARootCert2

Credential Access

T1003 OS Credential Dumping [1]

T-AzureADSSO

T1003.004 OS Credential Dumping: LSA Secrets [1]

P-ServiceDomainAdmin

T111 Two-Factor Authentication Interception [1]

P-DelegationKeyAdmin

T1110.002 Brute Force: Password Cracking [6]

A-LMHashAuthorized A-ReversiblePwd A-SmartCardPwdRotation A-SmartCardRequired S-C-Reversible S-Reversible

T1110.003 Brute Force: Password Spraying [7]

A-AnonymousAuthorizedGPO A-DsHeuristicsAllowAnonNSPI A-DsHeuristicsAnonymous A-LimitBlankPasswordUse A-NullSession A-PreWin2000Anonymous A-PreWin2000Other

T1187 Forced Authentication [12]

A-DC-Coerce A-DC-Spooler A-DC-WebClient A-DsHeuristicsDoNotVerifyUniqueness A-DsHeuristicsLDAPSecurity P-DelegationDCa2d2 P-DelegationDCsourcedeleg P-DelegationDCt2a4d P-DelegationEveryone P-UnconstrainedDelegation P-UnkownDelegation T-TGTDelegation

T1552 Unsecured Credentials [1]

A-UnixPwd

T1552.006 Unsecured Credentials: Group Policy Preferences [1]

A-PwdGPO

T1555.005 Credentials from Password Stores: Password Managers [1]

A-LAPS-Joined-Computers

T1557 Man-in-the-Middle [11]

A-CertEnrollChannelBinding A-CertEnrollHttp A-DCLdapSign A-DCLdapsChannelBinding A-DnsZoneAUCreateChild A-DnsZoneUpdate1 A-DnsZoneUpdate2 A-LDAPSigningDisabled A-SMB2SignatureNotEnabled A-SMB2SignatureNotRequired T-Inactive

T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay [4]

A-HardenedPaths A-NoGPOLLMNR S-OldNtlm S-SMB-v1

T1558 Steal or Forge Kerberos Tickets [7]

A-CertTempAgent A-CertTempAnyPurpose A-CertTempAnyone A-CertTempCustomSubject A-CertTempNoSecurity S-KerberosArmoring S-KerberosArmoringDC

T1558.001 Steal or Forge Kerberos Tickets: Golden Ticket [1]

A-Krbtgt

T1558.003 Steal or Forge Kerberos Tickets: Kerberoasting [1]

P-Kerberoasting

T1558.004 Steal or Forge Kerberos Tickets: AS-REP Roasting [4]

S-AesNotEnabled S-DesEnabled S-NoPreAuth S-NoPreAuthAdmin

Discovery

T1018 Remote System Discovery [2]

A-DnsZoneTransfert A-RootDseAnonBinding

T1069.002 Permission Groups Discovery: Domain Groups [2]

P-ControlPathIndirectEveryone P-ControlPathIndirectMany

T1087.001 Account Discovery: Local Account [1]

A-NoNetSessionHardening

T1201 Password Policy Discovery [2]

A-MinPwdLen A-NoServicePolicy

Lateral Movement

T1210 Exploitation of Remote Services [3]

A-PreWin2000AuthenticatedUsers T-FileDeployedOutOfDomain T-ScriptOutOfDomain

T1563 Remote Service Session Hijacking [1]

A-NTFRSOnSysvol

Mitigations

Number of Mitre rules matched: 7

Number of PingCastle rules not covered: 81

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

A-DCRefuseComputerPwdChange A-Guest A-MembershipEveryone P-DangerousExtendedRight P-Delegated P-DelegationDCa2d2 P-DelegationDCsourcedeleg P-DelegationDCt2a4d P-DelegationEveryone P-DelegationFileDeployed P-DelegationGPOData P-DelegationKeyAdmin P-DelegationLoginScript P-DsHeuristicsDoListObject P-ExchangeAdminSDHolder P-ExchangePrivEsc P-PrivilegeEveryone P-RODCAdminRevealed P-RODCAllowedGroup P-RODCDeniedGroup P-RODCKrbtgtOrphan P-RODCNeverReveal P-RODCRevealOnDemand P-RODCSYSVOLWrite P-UnconstrainedDelegation P-UnkownDelegation P-UnprotectedOU S-C-PrimaryGroup S-DC-SubnetMissing S-DefenderASR S-Duplicate S-FirewallScript S-FolderOptions S-JavaSchema S-PrimaryGroup S-PwdLastSet-45 S-PwdLastSet-90 S-PwdLastSet-Cluster S-PwdLastSet-DC S-PwdNeverExpires S-PwdNotRequired S-SIDHistory S-TerminalServicesGPO T-AlgsAES T-SIDFiltering T-SIDHistoryDangerous T-SIDHistorySameDomain T-SIDHistoryUnknownDomain T-TGTDelegation

Mitre Att&ck - Mitigation - Audit [3]

A-AuditDC A-AuditPowershell P-RecycleBin

Mitre Att&ck - Mitigation - Data Backup [2]

A-BackupMetadata A-NotEnoughDC

Mitre Att&ck - Mitigation - Privileged Account Management [21]

A-AdminSDHolder A-LAPS-Not-Installed A-ProtectedUsers P-AdminEmailOn P-AdminLogin P-AdminNum P-AdminPwdTooOld P-DCOwner P-DNSAdmin P-DNSDelegation P-DsHeuristicsAdminSDExMask P-Inactive P-LoginDCEveryone P-LogonDenied P-OperatorsEmpty P-RecoveryModeUnprotected P-SchemaAdmin P-ServiceDomainAdmin P-TrustedCredManAccessPrivilege S-Domain$$$ T-Downlevel

Mitre Att&ck - Mitigation - Privileged Process Integrity [1]

P-ProtectedUsers

Mitre Att&ck - Mitigation - Update Software [23]

S-DC-2000 S-DC-2003 S-DC-2008 S-DC-2012 S-DC-NotUpdated S-FunctionalLevel1 S-FunctionalLevel3 S-FunctionalLevel4 S-OS-2000 S-OS-2003 S-OS-2008 S-OS-2012 S-OS-NT S-OS-Vista S-OS-W10 S-OS-Win7 S-OS-Win8 S-OS-XP S-Vuln-MS14-068 S-Vuln-MS17_010 S-WSUS-HTTP S-WSUS-NoPinning S-WSUS-UserProxy

Mitre Att&ck - Mitigation - User Account Management [6]

S-ADRegistration S-ADRegistrationSchema S-C-Inactive S-DC-Inactive S-DefaultOUChanged S-Inactive

ANSSI Rules mapping

This is the mapping of the ANSSI rules with PingCastle rules.

Number of ANSSI rules matched: 55

1: 21

2: 16

3: 15

4: 3

1Constrained authentication delegation to a domain controller service (link)

ANSSI ID : vuln1_delegation_a2d2

PingCastle ID : P-DelegationDCa2d2

1Constrained delegation with protocol transition to a domain controller service (link)

ANSSI ID : vuln1_delegation_t2a4d

PingCastle ID : P-DelegationDCt2a4d

1DC/RODC with an obsolete operating system (link)

ANSSI ID : vuln1_warning_dc_obsolete

PingCastle ID : S-DC-2000 S-DC-2003 S-DC-2008 S-DC-2012

1Dangerous Display Specifiers (link)

ANSSI ID : vuln1_display_specifier

PingCastle ID : P-DisplaySpecifier

123Dangerous dsHeuristics settings (link)

ANSSI ID : vuln1_dsheuristics_bad vuln2_dsheuristics_bad vuln3_dsheuristics_bad

PingCastle ID : A-DsHeuristicsAllowAnonNSPI A-DsHeuristicsAnonymous A-DsHeuristicsDoNotVerifyUniqueness A-DsHeuristicsLDAPSecurity P-DsHeuristicsAdminSDExMask

1Dangerous enrollment permission on authentication certificate templates (link)

ANSSI ID : vuln1_adcs_template_auth_enroll_with_name

PingCastle ID : A-CertTempAgent A-CertTempAnyPurpose A-CertTempAnyone A-CertTempCustomSubject A-CertTempNoSecurity

1Domain controllers in inconsistent state (link)

ANSSI ID : vuln1_dc_inconsistent_uac

PingCastle ID : S-DCRegistration

1Domain controllers with passwords unchanged for more than 45 days (link)

ANSSI ID : vuln1_password_change_dc_no_change

PingCastle ID : S-PwdLastSet-DC

1Dormant accounts (link)

ANSSI ID : vuln1_user_accounts_dormant

PingCastle ID : S-Inactive

1Inactive domain controllers (link)

ANSSI ID : vuln1_password_change_inactive_dc

PingCastle ID : S-DC-Inactive

13Insufficient forest and domains functional levels (link)

ANSSI ID : vuln1_functional_level vuln3_functional_level

PingCastle ID : S-FunctionalLevel1 S-FunctionalLevel3 S-FunctionalLevel4

1Kerberos pre-authentication disabled for privileged accounts (link)

ANSSI ID : vuln1_kerberos_properties_preauth_priv

PingCastle ID : S-NoPreAuthAdmin

1Large privileged group member count (link)

ANSSI ID : vuln1_privileged_members

PingCastle ID : P-AdminNum

13Misconfigured DNS zones (link)

ANSSI ID : vuln1_dnszone_bad_prop vuln3_dnszone_bad_prop

PingCastle ID : A-DnsZoneUpdate1 A-DnsZoneUpdate2

1Outbound forest trust relationships with sID History enabled (link)

ANSSI ID : vuln1_trusts_forest_sidhistory

PingCastle ID : T-SIDFiltering

1Privileged account passwords age too old (link)

ANSSI ID : vuln1_password_change_priv

PingCastle ID : P-AdminPwdTooOld

1Privileged accounts with SPN (link)

ANSSI ID : vuln1_spn_priv

PingCastle ID : P-Kerberoasting

1Privileged accounts with never-expiring passwords (link)

ANSSI ID : vuln1_dont_expire_priv

PingCastle ID : P-ServiceDomainAdmin

1Resource-based constrained delegation on domain controlers (link)

ANSSI ID : vuln1_delegation_sourcedeleg

PingCastle ID : P-DelegationDCsourcedeleg

1Unfiltered outbound domain trust relationship (link)

ANSSI ID : vuln1_trusts_domain_notfiltered

PingCastle ID : T-SIDFiltering

13Weak or vulnerable certificates (link)

ANSSI ID : vuln1_certificates_vuln vuln3_certificates_vuln

PingCastle ID : A-CertROCA A-CertWeakDSA A-CertWeakRsaComponent A-MD2IntermediateCert A-MD2RootCert A-MD4IntermediateCert A-MD4RootCert A-MD5IntermediateCert A-MD5RootCert A-SHA0IntermediateCert A-SHA0RootCert A-SHA1IntermediateCert A-SHA1RootCert A-WeakRSARootCert A-WeakRSARootCert2

2Accounts or groups with unexpected SID history (link)

ANSSI ID : vuln2_sidhistory_dangerous

PingCastle ID : T-SIDHistoryDangerous

2Accounts with never-expiring passwords (link)

ANSSI ID : vuln2_dont_expire

PingCastle ID : S-PwdNeverExpires

2Bad Active Directory versions (link)

ANSSI ID : vuln2_adupdate_bad

PingCastle ID : P-DelegationKeyAdmin

2Kerberos pre-authentication disabled (link)

ANSSI ID : vuln2_kerberos_properties_preauth

PingCastle ID : S-NoPreAuth

2Krbtgt account password unchanged for more than a year (link)

ANSSI ID : vuln2_krbtgt

PingCastle ID : A-Krbtgt

2Privileged group members with weak password policy (link)

ANSSI ID : vuln2_privileged_members_password

PingCastle ID : A-MinPwdLen

2Privileged groups members having an adminCount attribute which is null or 0 (link)

ANSSI ID : vuln2_privileged_members_no_admincount

PingCastle ID : A-AdminSDHolder

2Privileged users revealed on RODC (link)

ANSSI ID : vuln2_rodc_priv_revealed

PingCastle ID : P-RODCAdminRevealed

2SYSVOL replication through NTFRS (link)

ANSSI ID : vuln2_sysvol_ntfrs

PingCastle ID : A-NTFRSOnSysvol

2Schema class allowing dangerous object creation (link)

ANSSI ID : vuln2_warning_schema_posssuperiors

PingCastle ID : S-ADRegistrationSchema

2Servers with passwords unchanged for more than 90 days (link)

ANSSI ID : vuln2_password_change_server_no_change_90

PingCastle ID : S-PwdLastSet-90

2The "Pre - Windows 2000 Compatible Access" group includes "Anonymous" (link)

ANSSI ID : vuln2_compatible_2000_anonymous

PingCastle ID : A-PreWin2000Anonymous

2Trust account passwords unchanged for more than a year (link)

ANSSI ID : vuln2_trusts_accounts

PingCastle ID : T-AzureADSSO T-Inactive

2Unconstrained authentication delegation (link)

ANSSI ID : vuln2_delegation_t4d

PingCastle ID : P-UnconstrainedDelegation

2Use of Kerberos with weak encryption (link)

ANSSI ID : vuln2_kerberos_properties_deskey

PingCastle ID : S-DesEnabled

2Windows server cluster accounts with passwords unchanged for more than 3 years (link)

ANSSI ID : vuln2_password_change_cluster_no_change_3years

PingCastle ID : S-PwdLastSet-Cluster

3Accounts or groups with SID history set (link)

ANSSI ID : vuln3_sidhistory_present

PingCastle ID : T-SIDHistorySameDomain T-SIDHistoryUnknownDomain

3Accounts with modified PrimaryGroupID (link)

ANSSI ID : vuln3_primary_group_id_nochange

PingCastle ID : S-C-PrimaryGroup S-PrimaryGroup

3Accounts with passwords stored using reversible encryption (link)

ANSSI ID : vuln3_reversible_password

PingCastle ID : A-ReversiblePwd A-UnixPwd S-C-Reversible S-Reversible

3Dangerous configuration of read-only domain controllers (RODC) (neverReveal) (link)

ANSSI ID : vuln3_rodc_never_reveal

PingCastle ID : P-RODCNeverReveal

3Dangerous configuration of read-only domain controllers (RODC) (reveal) (link)

ANSSI ID : vuln3_rodc_reveal

PingCastle ID : P-RODCRevealOnDemand

3Dangerous configuration of replication groups for read-only domain controllers (RODCs) (allow) (link)

ANSSI ID : vuln3_rodc_allowed_group

PingCastle ID : P-RODCAllowedGroup

3Dangerous configuration of replication groups for read-only domain controllers (RODCs) (denied) (link)

ANSSI ID : vuln3_rodc_denied_group

PingCastle ID : P-RODCDeniedGroup

3Inactive servers (link)

ANSSI ID : vuln3_password_change_inactive_servers

PingCastle ID : S-C-Inactive

3Inbound trust relationships with delegation (link)

ANSSI ID : vuln3_trusts_tgt_deleg

PingCastle ID : T-TGTDelegation

3Incorrect object owners (link)

ANSSI ID : vuln3_owner

PingCastle ID : P-DCOwner

3Orphan RODC krbtgt accounts (link)

ANSSI ID : vuln3_rodc_orphan_krbtgt

PingCastle ID : P-RODCKrbtgtOrphan

3Privileged accounts outside of the Protected Users group (link)

ANSSI ID : vuln3_protected_users

PingCastle ID : P-ProtectedUsers

3Servers with passwords unchanged for more than 45 days (link)

ANSSI ID : vuln3_password_change_server_no_change_45

PingCastle ID : S-PwdLastSet-45

3Service accounts supported encryption algorithms (link)

ANSSI ID : vuln3_kerberos_properties_encryption

PingCastle ID : S-AesNotEnabled

3Use of the "Pre-Windows 2000 Compatible Access" group (link)

ANSSI ID : vuln3_compatible_2000_not_default

PingCastle ID : A-PreWin2000Other

4DnsAdmins group members (link)

ANSSI ID : vuln4_dnsadmins

PingCastle ID : P-DNSAdmin

4Missing password expiration for smart card users (link)

ANSSI ID : vuln4_smartcard_expire_passwords

PingCastle ID : A-SmartCardPwdRotation

4Unrestricted domain join (link)

ANSSI ID : vuln4_user_accounts_machineaccountquota

PingCastle ID : S-ADRegistration