test.mysmartlogon.com - Healthcheck analysis

Date: 2023-04-24 - Engine version: 3.0.0.3 Beta

This report has been generated with the Auditor Edition of PingCastle ?.

This section focuses on the core security indicators.
Locate the sub-process determining the score and fix some rules in that area to get a score improvement.

Indicators

050100

Domain Risk Level: 100 / 100

It is the maximum score of the 4 indicators and one score cannot be higher than 100. The lower the better

050100

Stale Object : 100 /100

It is about operations related to user or computer objects

16 rules matched

050100

Trusts : 100 /100

It is about connections between two Active Directories

6 rules matched

050100

Privileged Accounts : 100 /100

It is about administrators of the Active Directory

21 rules matched

050100

Anomalies : 100 /100

It is about specific security control points

35 rules matched

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
Legend:
  score is 0 - no risk identified but some improvements detected
  score between 1 and 10 - a few actions have been identified
  score between 10 and 30 - rules should be looked with attention
  score higher than 30 - major risks identified

This section represents the maturity score (inspired from ANSSI).

Maturity Level:

12345

Maturity levels:

  • 1 Critical weaknesses and misconfigurations pose an immediate threat to all hosted resources. Corrective actions should be taken as soon as possible;
  • 2 Configuration and management weaknesses put all hosted resources at risk of a short-term compromise. Corrective actions should be carefully planned and implemented shortly;
  • 3 The Active Directory infrastructure does not appear to have been weakened from what default installation settings provide;
  • 4 The Active Directory infrastructure exhibits an enhanced level of security and management;
  • 5 The Active Directory infrastructure correctly implements the latest state-of-the-art administrative model and security features.
Level 1

22 rule(s) matched

Level 2

18 rule(s) matched

Level 3

30 rule(s) matched

Level 4

7 rule(s) matched

Level 5

1 rule(s) matched

To reach Level 2 you need to fix the following rules:

+ 80 Point(s)

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
[MITRE]T1552.006 Unsecured Credentials: Group Policy Preferences
[FR]ANSSI CERTFR-2015-ACT-046

Details:

The detail can be found in the Obfuscated Passwords

GPOloginpassword
WEF test ssss dddd
test nfc 2 administrator vletoux
test nfc 2 adiant vletoux
test nfc 2 test test
+ 50 Point(s)

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

Details:

The detail can be found in Trusts section

Trust
mil
+ 45 Point(s)

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.

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

Details:

The detail can be found in Privileges

GPOAccountPrivilege
Default Domain Controllers Policy Authenticated Users SeInteractiveLogonRight
Default Domain Controllers Policy Everyone SeInteractiveLogonRight
Default Domain Controllers Policy Authenticated Users SeRemoteInteractiveLogonRight
+ 25 Point(s)

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.

Points:

25 points per discovery

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controllerDelegateIdentifier
WIN-PGAHI2ECI8E ADIANT-VIRTUAL- S-1-5-21-4005144719-3948538632-2546531719-1133
+ 25 Point(s)

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.

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

Details:

The detail can be found in Control Paths Analysis

Group
Certificate Publishers
Domain Controllers
Domain Root
+ 15 Point(s)

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.

Points:

5 points per discovery

Documentation:

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

Details:

The detail can be found in Admin Groups

GroupUser
Administrators Adiant
Domain Administrators Adiant
Schema Administrators Adiant
+ 15 Point(s)

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:

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

Details:

The detail can be found in Admin Groups

+ 15 Point(s)

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

Details:

The detail can be found in Domain controllers

Domain controllerReason
WIN-PGAHI2ECI8E StartupTime=5/18/2022 8:39:36 AM
ADIANT-A7B9AAC6 LastComputerLogonDate=11/9/2018 7:29:04 AM
+ 15 Point(s)

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.

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
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space
[FR]ANSSI - Weak or vulnerable certificates (vuln1_certificates_vuln)1

Details:

The detail can be found in Certificates

SourceSubjectExpires
GPO:Default Domain Controllers Policy;Machine CN=localhost 2018-10-16 21:46:10Z
+ 15 Point(s)

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.

Points:

15 points if present

Documentation:

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

+ 15 Point(s)

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

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

Details:

The detail can be found in Certificate Templates

Name
CopyofCopyofEnrollmentAgent2
CopyofCopyofCopyofCopyofEnrollmentAgen4
+ 15 Point(s)

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

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

Details:

The detail can be found in Certificate Templates

Name
Copy of Enrollment Agent
+ 15 Point(s)

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)

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

Details:

The detail can be found in Certificate Templates

Name
SubCA
+ 15 Point(s)

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

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
[MITRE]T1557 Man-in-the-Middle
[FR]ANSSI - Misconfigured DNS zones (vuln1_dnszone_bad_prop)1

Details:
Zone
test.mysmartlogon.com
+ 15 Point(s)

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.

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

Details:

The detail can be found in Certificate Templates

Name
SubCA
SmartcardLogonforKSP
+ 10 Point(s)

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.

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_vuln_display_specifier)1
[MITRE]T1569 System Services

Details:
DNPathChanged
CN=user-Display,CN=410,CN=DisplaySpecifiers,CN=Configuration,DC=test,DC=mysmartlogon,DC=com 2,Reset Password…,\\gpaa\packages\resetpw.bat  2022-12-04 13:56:29Z
+ 10 Point(s)

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.

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

Details:

The detail can be found in Admin Groups

AccountCreationLastChanged
wrongaccount8 2016-03-28 10:40:52Z 2016-03-28 12:40:52Z
tset ☺☻♥♦♣♠•◘○◙♂♀♪♫☼ 2019-10-26 19:20:02Z Never
wrongAccount5 2015-06-26 15:47:18Z Never
wrongAccount1 2015-06-26 10:20:33Z Never
testitb1 2019-04-06 11:31:38Z 2019-04-06 13:31:38Z
test2 2019-03-23 07:19:15Z 2019-03-23 08:19:15Z
+ 10 Point(s)

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.

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

Details:

The detail can be found in Domain controllers

Domain controllerProblem
ADIANT-A7B9AAC6 InvalidUserAccount NoConfiguration
+ 5 Point(s)

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.

Points:

5 points per discovery

Documentation:

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

Details:

The detail can be found in User information and Computer information

AccountCreatedLastLogon
wrongaccount8 3/28/2016 10:40:52 AM Never
+ 5 Point(s)

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]
[MITRE]T1110.002 Brute Force: Password Cracking
[US]STIG V-3379 - The system is configured to store the LAN Manager hash of the password in the SAM.

Details:

The detail can be found in Security settings

GPOSetting
Default Domain Policy NoLMHash
+ 5 Point(s)

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
[MITRE]Mitre Att&ck - Mitigation - Update Software
[US]STIG V-8551 - The domain functional level must be at a Windows Server version still supported by Microsoft.
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R12 [subsection.3.1]

Details:

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

+ 5 Point(s)

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.

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-
[MITRE]Mitre Att&ck - Mitigation - User Account Management
[FR]ANSSI - Inactive domain controllers (vuln1_password_change_inactive_dc)1
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R45 [paragraph.3.6.6.2]

Details:

The detail can be found in Domain controllers

Domain controller
ADIANT-A7B9AAC6

To reach Level 3 you need to fix the following rules:

+ 60 Point(s)

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.

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

Details:

The detail can be found in Privileges

GPOAccountPrivilege
Default Domain Policy Everyone SeDebugPrivilege
Default Domain Policy Everyone SeLoadDriverPrivilege
test nfc 2 Everyone SeDebugPrivilege
test nfc 2 Everyone SeLoadDriverPrivilege
+ 50 Point(s)

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

Details:

The detail can be found in Krbtgt

+ 45 Point(s)

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.

Points:

15 points per discovery

Documentation:

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

Details:
GPOItemAccountRight
Test GPO site \\WIN-PGAHI2ECI8E.test.mysmartlogon.com\sysvol\test.mysmartlogon.com\Policies\{59C59FC3-6DCA-4659-9842-E9C490088449} Everyone FullControl
Default Domain Controllers Policy \\WIN-PGAHI2ECI8E.test.mysmartlogon.com\sysvol\test.mysmartlogon.com\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\GPT.INI Authenticated Users FullControl
Default Domain Controllers Policy \\WIN-PGAHI2ECI8E.test.mysmartlogon.com\sysvol\test.mysmartlogon.com\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Registry.pol Authenticated Users FullControl
+ 30 Point(s)

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.

Points:

15 points per discovery

Documentation:

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

Details:

The detail can be found in GPO Login script

ScriptAccountRight
\\test.mysmartlogon.com\sysvol\test.mysmartlogon.com\bin\test.ps1 Authenticated Users Modify, Synchronize
test.ps1 Authenticated Users Modify, Synchronize
+ 20 Point(s)

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

Details:

The detail can be found in Trusts section

Trust
mil
test4.mysmartlogon.com
+ 15 Point(s)

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://docs.microsoft.com/en-us/services-hub/health/remediation-steps-ad/remove-the-highly-insecure-des-encryption-from-user-accounts
[FR]ANSSI - Use of Kerberos with weak encryption (vuln2_kerberos_properties_deskey)2
[MITRE]T1558.004 Steal or Forge Kerberos Tickets: AS-REP Roasting

Details:

The detail can be found in User information and Computer information

+ 15 Point(s)

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:

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

Details:

The detail can be found in Delegations

DNdelegationright
DC=test,DC=mysmartlogon,DC=com Everyone GenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
+ 15 Point(s)

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.

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

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

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]

Details:

The detail can be found in Security settings

GPOValue
Windows default without an active GPO 3
+ 15 Point(s)

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.

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

Details:

The detail can be found in Security settings

GPO
Default Domain Policy
+ 15 Point(s)

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.

Points:

5 points per discovery

Documentation:

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

Details:

The detail can be found in GPO Deployed Files

GPOTypeFileNameAccountRight
WEF test Files (User section) \\test.mysmartlogon.com\sysvol\test.mysmartlogon.com\bin\test.txt Authenticated Users Modify, Synchronize
WEF test Application (Computer section) \\test.mysmartlogon.com\SYSVOL\test.mysmartlogon.com\bin\7z1900.msi Authenticated Users Modify, Synchronize
WEF test Application (Computer section) \\test.mysmartlogon.com\SYSVOL\test.mysmartlogon.com\bin\7z1900.msi Authenticated Users Modify, Synchronize
+ 10 Point(s)

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

Points:

10 points if present

Documentation:

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

Details:

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

Domain
S-1-5-18
test.mysmartlogon.com
+ 10 Point(s)

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

Details:

The detail can be found in Password policies

GPO
Test GPO site
Default Domain Policy
Default Domain Controllers Policy
PSO:test
PSO:test2
+ 10 Point(s)

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

Details:

The detail can be found in Domain controllers and Null Session

Domain controller
WIN-PGAHI2ECI8E
+ 5 Point(s)

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 * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows Server*"}

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
[MITRE]Mitre Att&ck - Mitigation - Update Software
[FR]ANSSI CERTFR-2005-INF-003

Details:

The detail can be found in Operating Systems

+ 5 Point(s)

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 * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows 1*"}

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

Details:

The detail can be found in Operating Systems

VersionNumberActive
Windows 10 1809 1 0
+ 5 Point(s)

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
[MITRE]T1110.003 Brute Force: Password Spraying
[US]STIG V-8547 - The Anonymous Logon and Everyone groups must not be members of the Pre-Windows 2000 Compatible Access group.
[FR]ANSSI - The "Pre - Windows 2000 Compatible Access" group includes "Anonymous" (vuln2_compatible_2000_anonymous)2

+ 5 Point(s)

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.

Points:

5 points if present

Documentation:


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

Details:

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

GPOKeyRequireIntegrityRequireMutualAuthenticationRequirePrivacy
Default Domain Controllers Policy \\*\SYSVOL Disabled Disabled Disabled
No GPO Found NETLOGON Not Set Not Set Not Set
+ 1 Point(s)

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.

Points:

1 points if present

Documentation:

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

Details:

The detail can be found in User information

To reach Level 4 you need to fix the following rules:

+ 50 Point(s)

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:

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

Details:

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

+ 30 Point(s)

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. Internally the hash of this password is used to sign the user's Kerberos tickets, making this account vulnerable to Silver ticket attacks. The rule is triggered 90 days after the last change of the attribute unicodePwd. This value is collected using the replication metadata of the attribute 589914

Advised solution:

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

Points:

30 points if present

Documentation:

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

Details:

The detail can be found in Smart Card and Password

+ 20 Point(s)

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

Details:

The detail can be found in Admin Groups

+ 15 Point(s)

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

Details:

The detail can be found in User information and Computer information

+ 15 Point(s)

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:

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

Details:

The detail can be found in User information and Computer information

+ 15 Point(s)

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

Details:

The detail can be found in the AdminSDHolder User List

+ 15 Point(s)

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]T1134.005 Access Token Manipulation: SID-History Injection
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Details:

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

SIDObject(s)
S-1-5-18 1
+ 15 Point(s)

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

Details:

The detail can be found in Backup

+ 10 Point(s)

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

Details:

The detail can be found in Domain controllers

Domain controllerOwner
CN=ADIANT-A7B9AAC6,CN=Computers,DC=test,DC=mysmartlogon,DC=com TEST\Administrator
+ 10 Point(s)

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.

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

+ 10 Point(s)

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:

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

Details:

The detail can be found in Admin Groups

+ 10 Point(s)

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
[MITRE]T1110.002 Brute Force: Password Cracking
[FR]ANSSI - Accounts with passwords stored using reversible encryption (vuln3_reversible_password)3

Details:

The detail can be found in Security settings

GPO
PSO:test2
+ 10 Point(s)

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.

Points:

10 points if present

Documentation:

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

Details:

The detail can be found in Audit settings
The table below shows the settings that were not found as configured in a GPO for a given domain controller.

TypeAuditProblemRationaleDomain controller
Advanced Policy Change / Authentication Policy Change No GPO check for audit success Collect events 4713, 4716, 4739, 4867, to track trust modifications ADIANT-A7B9AAC6
Advanced Account Management / Computer Account Management No GPO check for audit success Collect events 4741, 4742 to track computer changes ADIANT-A7B9AAC6
Advanced Detailed Tracking / DPAPI Activity No GPO check for audit success Collect event 4692 to track the export of DPAPI backup key ADIANT-A7B9AAC6
Advanced Account Logon / Kerberos Authentication Service No GPO check for audit success Collect events 4768, 4771 for kerberos authentication ADIANT-A7B9AAC6
Advanced Account Logon / Kerberos Service Ticket Operations No GPO check for audit success Collect events 4769 for kerberos authentication ADIANT-A7B9AAC6
Advanced Logon/Logoff / Logoff No GPO check for audit success Collect events 4634 for account logoff ADIANT-A7B9AAC6
Advanced Detailed Tracking / Process Creation No GPO check for audit success Collect event 4688 to get the history of executed programs ADIANT-A7B9AAC6
Advanced Account Management / Security Group Management No GPO check for audit success Collect events 4728, 4732, 4756 for group membership change ADIANT-A7B9AAC6
Advanced System / Security System Extension No GPO check for audit success Collect events 4610, 4697 to track lsass security packages and services ADIANT-A7B9AAC6
Advanced Privilege Use / Sensitive Privilege Use No GPO check for audit success Collect events 4672, 4673, 4674 for privileges tracking such as the debug one ADIANT-A7B9AAC6
Advanced Logon/Logoff / Special Logon No GPO check for audit success Collect event 4964 for special group attributed at logon ADIANT-A7B9AAC6
Advanced Account Management / User Account Management No GPO check for audit success Collect events 4720,22,23,38,65,66,80,94 for user account mamangement ADIANT-A7B9AAC6
+ 10 Point(s)

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
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay
[FR]ANSSI CERTFR-2017-ACT-019
[FR]ANSSI CERTFR-2016-ACT-039

Details:

The detail can be found in Domain controllers

Domain controller
WIN-PGAHI2ECI8E
+ 10 Point(s)

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.

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

Details:

The detail can be found in Domain controllers

DCProtocol
WIN-PGAHI2ECI8E Ssl2
WIN-PGAHI2ECI8E Ssl3
+ 5 Point(s)

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

+ 5 Point(s)

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.

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

Details:

The detail can be found in Security settings

GPO
Default Domain Policy
+ 5 Point(s)

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.

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

Details:

The detail can be found in LAPS

+ 5 Point(s)

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.

Points:

5 points if present

Documentation:

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

Details:
Missing
Domain Administrators
+ 5 Point(s)

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.

Points:

5 points if present

Documentation:

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

Details:
Member
CN=BlueHat,CN=Users,DC=test,DC=mysmartlogon,DC=com
+ 2 Point(s)

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.

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

+ 1 Point(s)

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

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

Details:

The detail can be found in Certificates

SourceSubjectModuleExpires
GPO:Default Domain Policy;Machine CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI 2048 2041-09-15 09:08:21Z
NTLMStore CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI 2048 2041-09-15 09:08:21Z
+ 1 Point(s)

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

Details:

The detail can be found in Certificates

GPOSubject
GPO:Default Domain Policy;Machine SERIALNUMBER=200804, CN=Foreigner CA, C=BE
GPO:Default Domain Policy;Machine CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
GPO:Default Domain Policy;Machine CN=COMODO Code Signing CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
NTLMStore CN=COMODO Code Signing CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
NTLMStore CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
NTLMStore CN=COMODO Code Signing CA, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
Informative rule

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

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

Details:
SettingPositionValue
LDAPAddAuthZVerifications 28th Not Set
LDAPOwnerModify 29th Not Set
Informative rule

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).
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space
[FR]ANSSI - Weak or vulnerable certificates (vuln3_certificates_vuln)3

Details:

The detail can be found in Certificates

GPOSubject
GPO:Default Domain Policy;Machine CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
GPO:Default Domain Policy;Machine CN=Belgium Root CA2, C=BE
GPO:Default Domain Policy;Machine CN=MaskTech CSCA, OU=Test Division, O=MaskTech GmbH, C=DE
GPO:Default Domain Policy;Machine CN=CA, DC=test, DC=mysmartlogon, DC=com
GPO:Default Domain Policy;Machine CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI
NTLMStore CN=CA, DC=test, DC=mysmartlogon, DC=com
NTLMStore CN=MaskTech CSCA, OU=Test Division, O=MaskTech GmbH, C=DE
NTLMStore CN=Belgium Root CA2, C=BE
NTLMStore CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI
NTLMStore CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
NTLMStore CN=CA, DC=test, DC=mysmartlogon, DC=com
Informative rule

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

Details:

The schema version is indicated in Domain Information

Informative rule

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.

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
[MITRE]Mitre Att&ck - Mitigation - Update Software
[FR]ANSSI - Insufficient forest and domains functional levels (vuln3_vuln_functional_level)3

Details:

The functional levels are indicated in Domain Information

TypeLevel
Domain Windows Server 2008 R2
Forest Windows Server 2008 R2
Informative rule

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

Details:

The detail can be found in Admin Groups

GroupMembers
Account Operators 1
Informative rule

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/
[MITRE]T1552 Unsecured Credentials
[FR]ANSSI - Accounts with passwords stored using reversible encryption (vuln3_reversible_password)3

Details:

The detail can be found in Unix Passwords

User
wrongaccount8
Informative rule

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.

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

Details:

The detail can be found in Security settings

To reach Level 5 you need to fix the following rules:

+ 15 Point(s)

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

Details:

The detail can be found in Delegations

DNdelegationright
CN=Users,DC=test,DC=mysmartlogon,DC=com S-1-5-21-4005144719-3948538632-2546531719-1115 EXT_RIGHT_FORCE_CHANGE_PWD
+ 1 Point(s)

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.

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

Details:
TrustReason
test4.mysmartlogon.com Not Configured
Informative rule

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Security settings

Informative rule

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.

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controller
WIN-PGAHI2ECI8E
Informative rule

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.

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

Details:
DNSZone
test.mysmartlogon.com
Informative rule

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

Details:

The detail can be found in Password Policies

Informative rule

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

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

Details:

The detail can be found in Admin Groups

To reach the maximum level you need to fix the following rules:

Informative rule

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.

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

This section represents an evaluation of the techniques available in the MITRE ATT&CK®

Techniques

Initial Access

1 technique(s) matched

Execution

1 technique(s) matched

Privilege Escalation

1 technique(s) matched

Defense Evasion

2 technique(s) matched

Credential Access

13 technique(s) matched

Discovery

3 technique(s) matched

Lateral Movement

1 technique(s) matched

Initial Access

T1078.003 Valid Accounts: Local Accounts [1]

+ 15 Point(s)

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.

Points:

15 points if present

Documentation:

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

Execution

T1569 System Services [1]

+ 10 Point(s)

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.

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_vuln_display_specifier)1
[MITRE]T1569 System Services

Details:
DNPathChanged
CN=user-Display,CN=410,CN=DisplaySpecifiers,CN=Configuration,DC=test,DC=mysmartlogon,DC=com 2,Reset Password…,\\gpaa\packages\resetpw.bat  2022-12-04 13:56:29Z

Privilege Escalation

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

+ 50 Point(s)

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:

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

Details:

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

+ 50 Point(s)

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

Details:

The detail can be found in Trusts section

Trust
mil
+ 15 Point(s)

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]T1134.005 Access Token Manipulation: SID-History Injection
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Details:

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

SIDObject(s)
S-1-5-18 1
+ 10 Point(s)

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

Points:

10 points if present

Documentation:

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

Details:

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

Domain
S-1-5-18
test.mysmartlogon.com

Defense Evasion

T1207 Rogue Domain Controller [1]

+ 10 Point(s)

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.

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

Details:

The detail can be found in Domain controllers

Domain controllerProblem
ADIANT-A7B9AAC6 InvalidUserAccount NoConfiguration

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

+ 15 Point(s)

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.

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
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space
[FR]ANSSI - Weak or vulnerable certificates (vuln1_certificates_vuln)1

Details:

The detail can be found in Certificates

SourceSubjectExpires
GPO:Default Domain Controllers Policy;Machine CN=localhost 2018-10-16 21:46:10Z
+ 10 Point(s)

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.

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

Details:

The detail can be found in Domain controllers

DCProtocol
WIN-PGAHI2ECI8E Ssl2
WIN-PGAHI2ECI8E Ssl3
+ 1 Point(s)

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

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

Details:

The detail can be found in Certificates

SourceSubjectModuleExpires
GPO:Default Domain Policy;Machine CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI 2048 2041-09-15 09:08:21Z
NTLMStore CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI 2048 2041-09-15 09:08:21Z
+ 1 Point(s)

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

Details:

The detail can be found in Certificates

GPOSubject
GPO:Default Domain Policy;Machine SERIALNUMBER=200804, CN=Foreigner CA, C=BE
GPO:Default Domain Policy;Machine CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
GPO:Default Domain Policy;Machine CN=COMODO Code Signing CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
NTLMStore CN=COMODO Code Signing CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
NTLMStore CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
NTLMStore CN=COMODO Code Signing CA, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
Informative rule

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).
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space
[FR]ANSSI - Weak or vulnerable certificates (vuln3_certificates_vuln)3

Details:

The detail can be found in Certificates

GPOSubject
GPO:Default Domain Policy;Machine CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
GPO:Default Domain Policy;Machine CN=Belgium Root CA2, C=BE
GPO:Default Domain Policy;Machine CN=MaskTech CSCA, OU=Test Division, O=MaskTech GmbH, C=DE
GPO:Default Domain Policy;Machine CN=CA, DC=test, DC=mysmartlogon, DC=com
GPO:Default Domain Policy;Machine CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI
NTLMStore CN=CA, DC=test, DC=mysmartlogon, DC=com
NTLMStore CN=MaskTech CSCA, OU=Test Division, O=MaskTech GmbH, C=DE
NTLMStore CN=Belgium Root CA2, C=BE
NTLMStore CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI
NTLMStore CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
NTLMStore CN=CA, DC=test, DC=mysmartlogon, DC=com

Credential Access

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

+ 15 Point(s)

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:

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

Details:

The detail can be found in Admin Groups

T1110.002 Brute Force: Password Cracking [3]

+ 30 Point(s)

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. Internally the hash of this password is used to sign the user's Kerberos tickets, making this account vulnerable to Silver ticket attacks. The rule is triggered 90 days after the last change of the attribute unicodePwd. This value is collected using the replication metadata of the attribute 589914

Advised solution:

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

Points:

30 points if present

Documentation:

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

Details:

The detail can be found in Smart Card and Password

+ 10 Point(s)

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
[MITRE]T1110.002 Brute Force: Password Cracking
[FR]ANSSI - Accounts with passwords stored using reversible encryption (vuln3_reversible_password)3

Details:

The detail can be found in Security settings

GPO
PSO:test2
+ 5 Point(s)

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]
[MITRE]T1110.002 Brute Force: Password Cracking
[US]STIG V-3379 - The system is configured to store the LAN Manager hash of the password in the SAM.

Details:

The detail can be found in Security settings

GPOSetting
Default Domain Policy NoLMHash

T1110.003 Brute Force: Password Spraying [3]

+ 10 Point(s)

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

Details:

The detail can be found in Domain controllers and Null Session

Domain controller
WIN-PGAHI2ECI8E
+ 5 Point(s)

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
[MITRE]T1110.003 Brute Force: Password Spraying
[US]STIG V-8547 - The Anonymous Logon and Everyone groups must not be members of the Pre-Windows 2000 Compatible Access group.
[FR]ANSSI - The "Pre - Windows 2000 Compatible Access" group includes "Anonymous" (vuln2_compatible_2000_anonymous)2

+ 2 Point(s)

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.

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

T1187 Forced Authentication [5]

+ 25 Point(s)

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.

Points:

25 points per discovery

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controllerDelegateIdentifier
WIN-PGAHI2ECI8E ADIANT-VIRTUAL- S-1-5-21-4005144719-3948538632-2546531719-1133
+ 15 Point(s)

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

Details:

The detail can be found in Delegations

DNdelegationright
CN=Users,DC=test,DC=mysmartlogon,DC=com S-1-5-21-4005144719-3948538632-2546531719-1115 EXT_RIGHT_FORCE_CHANGE_PWD
+ 15 Point(s)

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:

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

Details:

The detail can be found in Delegations

DNdelegationright
DC=test,DC=mysmartlogon,DC=com Everyone GenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
Informative rule

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

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

Details:
SettingPositionValue
LDAPAddAuthZVerifications 28th Not Set
LDAPOwnerModify 29th Not Set
Informative rule

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.

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controller
WIN-PGAHI2ECI8E

T1552 Unsecured Credentials [1]

Informative rule

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/
[MITRE]T1552 Unsecured Credentials
[FR]ANSSI - Accounts with passwords stored using reversible encryption (vuln3_reversible_password)3

Details:

The detail can be found in Unix Passwords

User
wrongaccount8

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

+ 80 Point(s)

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
[MITRE]T1552.006 Unsecured Credentials: Group Policy Preferences
[FR]ANSSI CERTFR-2015-ACT-046

Details:

The detail can be found in the Obfuscated Passwords

GPOloginpassword
WEF test ssss dddd
test nfc 2 administrator vletoux
test nfc 2 adiant vletoux
test nfc 2 test test

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

+ 5 Point(s)

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.

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

Details:

The detail can be found in LAPS

T1557 Man-in-the-Middle [4]

+ 20 Point(s)

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

Details:

The detail can be found in Trusts section

Trust
mil
test4.mysmartlogon.com
+ 15 Point(s)

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

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
[MITRE]T1557 Man-in-the-Middle
[FR]ANSSI - Misconfigured DNS zones (vuln1_dnszone_bad_prop)1

Details:
Zone
test.mysmartlogon.com
+ 5 Point(s)

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.

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

Details:

The detail can be found in Security settings

GPO
Default Domain Policy
Informative rule

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.

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

Details:
DNSZone
test.mysmartlogon.com

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

+ 15 Point(s)

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.

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

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

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]

Details:

The detail can be found in Security settings

GPOValue
Windows default without an active GPO 3
+ 10 Point(s)

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
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay
[FR]ANSSI CERTFR-2017-ACT-019
[FR]ANSSI CERTFR-2016-ACT-039

Details:

The detail can be found in Domain controllers

Domain controller
WIN-PGAHI2ECI8E
+ 5 Point(s)

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.

Points:

5 points if present

Documentation:


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

Details:

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

GPOKeyRequireIntegrityRequireMutualAuthenticationRequirePrivacy
Default Domain Controllers Policy \\*\SYSVOL Disabled Disabled Disabled
No GPO Found NETLOGON Not Set Not Set Not Set

T1558 Steal or Forge Kerberos Tickets [4]

+ 15 Point(s)

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

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

Details:

The detail can be found in Certificate Templates

Name
CopyofCopyofEnrollmentAgent2
CopyofCopyofCopyofCopyofEnrollmentAgen4
+ 15 Point(s)

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

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

Details:

The detail can be found in Certificate Templates

Name
Copy of Enrollment Agent
+ 15 Point(s)

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)

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

Details:

The detail can be found in Certificate Templates

Name
SubCA
+ 15 Point(s)

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.

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

Details:

The detail can be found in Certificate Templates

Name
SubCA
SmartcardLogonforKSP

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

+ 50 Point(s)

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

Details:

The detail can be found in Krbtgt

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

+ 15 Point(s)

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.

Points:

5 points per discovery

Documentation:

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

Details:

The detail can be found in Admin Groups

GroupUser
Administrators Adiant
Domain Administrators Adiant
Schema Administrators Adiant

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

+ 15 Point(s)

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://docs.microsoft.com/en-us/services-hub/health/remediation-steps-ad/remove-the-highly-insecure-des-encryption-from-user-accounts
[FR]ANSSI - Use of Kerberos with weak encryption (vuln2_kerberos_properties_deskey)2
[MITRE]T1558.004 Steal or Forge Kerberos Tickets: AS-REP Roasting

Details:

The detail can be found in User information and Computer information

+ 5 Point(s)

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.

Points:

5 points per discovery

Documentation:

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

Details:

The detail can be found in User information and Computer information

AccountCreatedLastLogon
wrongaccount8 3/28/2016 10:40:52 AM Never

Discovery

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

+ 25 Point(s)

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.

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

Details:

The detail can be found in Control Paths Analysis

Group
Certificate Publishers
Domain Controllers
Domain Root

T1087.001 Account Discovery: Local Account [1]

Informative rule

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Security settings

T1201 Password Policy Discovery [2]

+ 10 Point(s)

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

Details:

The detail can be found in Password policies

GPO
Test GPO site
Default Domain Policy
Default Domain Controllers Policy
PSO:test
PSO:test2
Informative rule

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

Details:

The detail can be found in Password Policies

Lateral Movement

T1210 Exploitation of Remote Services [1]

Informative rule

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.

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


Mitigations

Audit

Mitigation did matched

Active Directory Configuration

Mitigation did matched

Data Backup

Mitigation did matched

Privileged Account Management

Mitigation did matched

Privileged Process Integrity

No match

Update Software

Mitigation did matched

User Account Management

Mitigation did matched

Audit

Mitre Att&ck - Mitigation - Audit [2]

+ 10 Point(s)

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.

Points:

10 points if present

Documentation:

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

Details:

The detail can be found in Audit settings
The table below shows the settings that were not found as configured in a GPO for a given domain controller.

TypeAuditProblemRationaleDomain controller
Advanced Policy Change / Authentication Policy Change No GPO check for audit success Collect events 4713, 4716, 4739, 4867, to track trust modifications ADIANT-A7B9AAC6
Advanced Account Management / Computer Account Management No GPO check for audit success Collect events 4741, 4742 to track computer changes ADIANT-A7B9AAC6
Advanced Detailed Tracking / DPAPI Activity No GPO check for audit success Collect event 4692 to track the export of DPAPI backup key ADIANT-A7B9AAC6
Advanced Account Logon / Kerberos Authentication Service No GPO check for audit success Collect events 4768, 4771 for kerberos authentication ADIANT-A7B9AAC6
Advanced Account Logon / Kerberos Service Ticket Operations No GPO check for audit success Collect events 4769 for kerberos authentication ADIANT-A7B9AAC6
Advanced Logon/Logoff / Logoff No GPO check for audit success Collect events 4634 for account logoff ADIANT-A7B9AAC6
Advanced Detailed Tracking / Process Creation No GPO check for audit success Collect event 4688 to get the history of executed programs ADIANT-A7B9AAC6
Advanced Account Management / Security Group Management No GPO check for audit success Collect events 4728, 4732, 4756 for group membership change ADIANT-A7B9AAC6
Advanced System / Security System Extension No GPO check for audit success Collect events 4610, 4697 to track lsass security packages and services ADIANT-A7B9AAC6
Advanced Privilege Use / Sensitive Privilege Use No GPO check for audit success Collect events 4672, 4673, 4674 for privileges tracking such as the debug one ADIANT-A7B9AAC6
Advanced Logon/Logoff / Special Logon No GPO check for audit success Collect event 4964 for special group attributed at logon ADIANT-A7B9AAC6
Advanced Account Management / User Account Management No GPO check for audit success Collect events 4720,22,23,38,65,66,80,94 for user account mamangement ADIANT-A7B9AAC6
Informative rule

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.

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

Details:

The detail can be found in Security settings

Active Directory Configuration

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

+ 60 Point(s)

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.

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

Details:

The detail can be found in Privileges

GPOAccountPrivilege
Default Domain Policy Everyone SeDebugPrivilege
Default Domain Policy Everyone SeLoadDriverPrivilege
test nfc 2 Everyone SeDebugPrivilege
test nfc 2 Everyone SeLoadDriverPrivilege
+ 50 Point(s)

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:

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

Details:

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

+ 50 Point(s)

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

Details:

The detail can be found in Trusts section

Trust
mil
+ 45 Point(s)

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.

Points:

15 points per discovery

Documentation:

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

Details:
GPOItemAccountRight
Test GPO site \\WIN-PGAHI2ECI8E.test.mysmartlogon.com\sysvol\test.mysmartlogon.com\Policies\{59C59FC3-6DCA-4659-9842-E9C490088449} Everyone FullControl
Default Domain Controllers Policy \\WIN-PGAHI2ECI8E.test.mysmartlogon.com\sysvol\test.mysmartlogon.com\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\GPT.INI Authenticated Users FullControl
Default Domain Controllers Policy \\WIN-PGAHI2ECI8E.test.mysmartlogon.com\sysvol\test.mysmartlogon.com\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Registry.pol Authenticated Users FullControl
+ 30 Point(s)

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.

Points:

15 points per discovery

Documentation:

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

Details:

The detail can be found in GPO Login script

ScriptAccountRight
\\test.mysmartlogon.com\sysvol\test.mysmartlogon.com\bin\test.ps1 Authenticated Users Modify, Synchronize
test.ps1 Authenticated Users Modify, Synchronize
+ 25 Point(s)

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.

Points:

25 points per discovery

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controllerDelegateIdentifier
WIN-PGAHI2ECI8E ADIANT-VIRTUAL- S-1-5-21-4005144719-3948538632-2546531719-1133
+ 20 Point(s)

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

Details:

The detail can be found in Admin Groups

+ 15 Point(s)

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:

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

Details:

The detail can be found in Delegations

DNdelegationright
DC=test,DC=mysmartlogon,DC=com Everyone GenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
+ 15 Point(s)

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.

Points:

15 points if present

Documentation:

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

+ 15 Point(s)

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

Details:

The detail can be found in Delegations

DNdelegationright
CN=Users,DC=test,DC=mysmartlogon,DC=com S-1-5-21-4005144719-3948538632-2546531719-1115 EXT_RIGHT_FORCE_CHANGE_PWD
+ 15 Point(s)

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:

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

Details:

The detail can be found in User information and Computer information

+ 15 Point(s)

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

Details:

The detail can be found in User information and Computer information

+ 15 Point(s)

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]T1134.005 Access Token Manipulation: SID-History Injection
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Details:

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

SIDObject(s)
S-1-5-18 1
+ 15 Point(s)

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.

Points:

5 points per discovery

Documentation:

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

Details:

The detail can be found in GPO Deployed Files

GPOTypeFileNameAccountRight
WEF test Files (User section) \\test.mysmartlogon.com\sysvol\test.mysmartlogon.com\bin\test.txt Authenticated Users Modify, Synchronize
WEF test Application (Computer section) \\test.mysmartlogon.com\SYSVOL\test.mysmartlogon.com\bin\7z1900.msi Authenticated Users Modify, Synchronize
WEF test Application (Computer section) \\test.mysmartlogon.com\SYSVOL\test.mysmartlogon.com\bin\7z1900.msi Authenticated Users Modify, Synchronize
+ 10 Point(s)

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

Points:

10 points if present

Documentation:

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

Details:

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

Domain
S-1-5-18
test.mysmartlogon.com
+ 5 Point(s)

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.

Points:

5 points if present

Documentation:

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

Details:
Member
CN=BlueHat,CN=Users,DC=test,DC=mysmartlogon,DC=com
+ 5 Point(s)

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.

Points:

5 points if present

Documentation:

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

Details:
Missing
Domain Administrators
+ 1 Point(s)

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.

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

Details:
TrustReason
test4.mysmartlogon.com Not Configured
+ 1 Point(s)

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.

Points:

1 points if present

Documentation:

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

Details:

The detail can be found in User information

Data Backup

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

+ 15 Point(s)

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

Details:

The detail can be found in Backup

Privileged Account Management

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

+ 45 Point(s)

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.

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

Details:

The detail can be found in Privileges

GPOAccountPrivilege
Default Domain Controllers Policy Authenticated Users SeInteractiveLogonRight
Default Domain Controllers Policy Everyone SeInteractiveLogonRight
Default Domain Controllers Policy Authenticated Users SeRemoteInteractiveLogonRight
+ 15 Point(s)

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.

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

Details:

The detail can be found in Security settings

GPO
Default Domain Policy
+ 15 Point(s)

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:

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

Details:

The detail can be found in Admin Groups

+ 15 Point(s)

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

Details:

The detail can be found in the AdminSDHolder User List

+ 10 Point(s)

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

Details:

The detail can be found in Domain controllers

Domain controllerOwner
CN=ADIANT-A7B9AAC6,CN=Computers,DC=test,DC=mysmartlogon,DC=com TEST\Administrator
+ 10 Point(s)

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:

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

Details:

The detail can be found in Admin Groups

+ 10 Point(s)

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.

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

Details:

The detail can be found in Admin Groups

AccountCreationLastChanged
wrongaccount8 2016-03-28 10:40:52Z 2016-03-28 12:40:52Z
tset ☺☻♥♦♣♠•◘○◙♂♀♪♫☼ 2019-10-26 19:20:02Z Never
wrongAccount5 2015-06-26 15:47:18Z Never
wrongAccount1 2015-06-26 10:20:33Z Never
testitb1 2019-04-06 11:31:38Z 2019-04-06 13:31:38Z
test2 2019-03-23 07:19:15Z 2019-03-23 08:19:15Z
+ 5 Point(s)

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

Informative rule

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

Details:

The schema version is indicated in Domain Information

Informative rule

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

Details:

The detail can be found in Admin Groups

GroupMembers
Account Operators 1
Informative rule

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

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

Details:

The detail can be found in Admin Groups

Update Software

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

+ 15 Point(s)

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

Details:

The detail can be found in Domain controllers

Domain controllerReason
WIN-PGAHI2ECI8E StartupTime=5/18/2022 8:39:36 AM
ADIANT-A7B9AAC6 LastComputerLogonDate=11/9/2018 7:29:04 AM
+ 5 Point(s)

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 * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows 1*"}

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

Details:

The detail can be found in Operating Systems

VersionNumberActive
Windows 10 1809 1 0
+ 5 Point(s)

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 * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows Server*"}

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
[MITRE]Mitre Att&ck - Mitigation - Update Software
[FR]ANSSI CERTFR-2005-INF-003

Details:

The detail can be found in Operating Systems

+ 5 Point(s)

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
[MITRE]Mitre Att&ck - Mitigation - Update Software
[US]STIG V-8551 - The domain functional level must be at a Windows Server version still supported by Microsoft.
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R12 [subsection.3.1]

Details:

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

Informative rule

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.

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
[MITRE]Mitre Att&ck - Mitigation - Update Software
[FR]ANSSI - Insufficient forest and domains functional levels (vuln3_vuln_functional_level)3

Details:

The functional levels are indicated in Domain Information

TypeLevel
Domain Windows Server 2008 R2
Forest Windows Server 2008 R2

User Account Management

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

+ 10 Point(s)

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.

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

+ 5 Point(s)

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.

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-
[MITRE]Mitre Att&ck - Mitigation - User Account Management
[FR]ANSSI - Inactive domain controllers (vuln1_password_change_inactive_dc)1
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R45 [paragraph.3.6.6.2]

Details:

The detail can be found in Domain controllers

Domain controller
ADIANT-A7B9AAC6
050100

Stale Objects : 100 /100

It is about operations related to user or computer objects

+ 15 Point(s)

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://docs.microsoft.com/en-us/services-hub/health/remediation-steps-ad/remove-the-highly-insecure-des-encryption-from-user-accounts
[FR]ANSSI - Use of Kerberos with weak encryption (vuln2_kerberos_properties_deskey)2
[MITRE]T1558.004 Steal or Forge Kerberos Tickets: AS-REP Roasting

Details:

The detail can be found in User information and Computer information

+ 15 Point(s)

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.

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

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

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]

Details:

The detail can be found in Security settings

GPOValue
Windows default without an active GPO 3
+ 15 Point(s)

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

Details:

The detail can be found in Domain controllers

Domain controllerReason
WIN-PGAHI2ECI8E StartupTime=5/18/2022 8:39:36 AM
ADIANT-A7B9AAC6 LastComputerLogonDate=11/9/2018 7:29:04 AM
+ 15 Point(s)

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:

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

Details:

The detail can be found in User information and Computer information

+ 15 Point(s)

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

Details:

The detail can be found in User information and Computer information

+ 15 Point(s)

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]T1134.005 Access Token Manipulation: SID-History Injection
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

Details:

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

SIDObject(s)
S-1-5-18 1
+ 10 Point(s)

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.

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

Details:

The detail can be found in Domain controllers

Domain controllerProblem
ADIANT-A7B9AAC6 InvalidUserAccount NoConfiguration
+ 10 Point(s)

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
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay
[FR]ANSSI CERTFR-2017-ACT-019
[FR]ANSSI CERTFR-2016-ACT-039

Details:

The detail can be found in Domain controllers

Domain controller
WIN-PGAHI2ECI8E
+ 10 Point(s)

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.

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

+ 5 Point(s)

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 * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows Server*"}

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
[MITRE]Mitre Att&ck - Mitigation - Update Software
[FR]ANSSI CERTFR-2005-INF-003

Details:

The detail can be found in Operating Systems

+ 5 Point(s)

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 * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows 1*"}

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

Details:

The detail can be found in Operating Systems

VersionNumberActive
Windows 10 1809 1 0
+ 5 Point(s)

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.

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-
[MITRE]Mitre Att&ck - Mitigation - User Account Management
[FR]ANSSI - Inactive domain controllers (vuln1_password_change_inactive_dc)1
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R45 [paragraph.3.6.6.2]

Details:

The detail can be found in Domain controllers

Domain controller
ADIANT-A7B9AAC6
+ 5 Point(s)

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
[MITRE]Mitre Att&ck - Mitigation - Update Software
[US]STIG V-8551 - The domain functional level must be at a Windows Server version still supported by Microsoft.
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R12 [subsection.3.1]

Details:

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

+ 5 Point(s)

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.

Points:

5 points per discovery

Documentation:

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

Details:

The detail can be found in User information and Computer information

AccountCreatedLastLogon
wrongaccount8 3/28/2016 10:40:52 AM Never
+ 1 Point(s)

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.

Points:

1 points if present

Documentation:

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

Details:

The detail can be found in User information

Informative rule

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.

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
[MITRE]Mitre Att&ck - Mitigation - Update Software
[FR]ANSSI - Insufficient forest and domains functional levels (vuln3_vuln_functional_level)3

Details:

The functional levels are indicated in Domain Information

TypeLevel
Domain Windows Server 2008 R2
Forest Windows Server 2008 R2
050100

Privileged Accounts : 100 /100

It is about administrators of the Active Directory

+ 60 Point(s)

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.

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

Details:

The detail can be found in Privileges

GPOAccountPrivilege
Default Domain Policy Everyone SeDebugPrivilege
Default Domain Policy Everyone SeLoadDriverPrivilege
test nfc 2 Everyone SeDebugPrivilege
test nfc 2 Everyone SeLoadDriverPrivilege
+ 45 Point(s)

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.

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

Details:

The detail can be found in Privileges

GPOAccountPrivilege
Default Domain Controllers Policy Authenticated Users SeInteractiveLogonRight
Default Domain Controllers Policy Everyone SeInteractiveLogonRight
Default Domain Controllers Policy Authenticated Users SeRemoteInteractiveLogonRight
+ 45 Point(s)

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.

Points:

15 points per discovery

Documentation:

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

Details:
GPOItemAccountRight
Test GPO site \\WIN-PGAHI2ECI8E.test.mysmartlogon.com\sysvol\test.mysmartlogon.com\Policies\{59C59FC3-6DCA-4659-9842-E9C490088449} Everyone FullControl
Default Domain Controllers Policy \\WIN-PGAHI2ECI8E.test.mysmartlogon.com\sysvol\test.mysmartlogon.com\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\GPT.INI Authenticated Users FullControl
Default Domain Controllers Policy \\WIN-PGAHI2ECI8E.test.mysmartlogon.com\sysvol\test.mysmartlogon.com\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Registry.pol Authenticated Users FullControl
+ 30 Point(s)

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.

Points:

15 points per discovery

Documentation:

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

Details:

The detail can be found in GPO Login script

ScriptAccountRight
\\test.mysmartlogon.com\sysvol\test.mysmartlogon.com\bin\test.ps1 Authenticated Users Modify, Synchronize
test.ps1 Authenticated Users Modify, Synchronize
+ 25 Point(s)

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.

Points:

25 points per discovery

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controllerDelegateIdentifier
WIN-PGAHI2ECI8E ADIANT-VIRTUAL- S-1-5-21-4005144719-3948538632-2546531719-1133
+ 25 Point(s)

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.

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

Details:

The detail can be found in Control Paths Analysis

Group
Certificate Publishers
Domain Controllers
Domain Root
+ 20 Point(s)

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

Details:

The detail can be found in Admin Groups

+ 15 Point(s)

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.

Points:

5 points per discovery

Documentation:

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

Details:

The detail can be found in Admin Groups

GroupUser
Administrators Adiant
Domain Administrators Adiant
Schema Administrators Adiant
+ 15 Point(s)

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.

Points:

5 points per discovery

Documentation:

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

Details:

The detail can be found in GPO Deployed Files

GPOTypeFileNameAccountRight
WEF test Files (User section) \\test.mysmartlogon.com\sysvol\test.mysmartlogon.com\bin\test.txt Authenticated Users Modify, Synchronize
WEF test Application (Computer section) \\test.mysmartlogon.com\SYSVOL\test.mysmartlogon.com\bin\7z1900.msi Authenticated Users Modify, Synchronize
WEF test Application (Computer section) \\test.mysmartlogon.com\SYSVOL\test.mysmartlogon.com\bin\7z1900.msi Authenticated Users Modify, Synchronize
+ 15 Point(s)

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.

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

Details:

The detail can be found in Security settings

GPO
Default Domain Policy
+ 15 Point(s)

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

Details:

The detail can be found in Delegations

DNdelegationright
CN=Users,DC=test,DC=mysmartlogon,DC=com S-1-5-21-4005144719-3948538632-2546531719-1115 EXT_RIGHT_FORCE_CHANGE_PWD
+ 15 Point(s)

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:

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

Details:

The detail can be found in Admin Groups

+ 15 Point(s)

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:

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

Details:

The detail can be found in Delegations

DNdelegationright
DC=test,DC=mysmartlogon,DC=com Everyone GenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
+ 10 Point(s)

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

Details:

The detail can be found in Domain controllers

Domain controllerOwner
CN=ADIANT-A7B9AAC6,CN=Computers,DC=test,DC=mysmartlogon,DC=com TEST\Administrator
+ 10 Point(s)

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.

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_vuln_display_specifier)1
[MITRE]T1569 System Services

Details:
DNPathChanged
CN=user-Display,CN=410,CN=DisplaySpecifiers,CN=Configuration,DC=test,DC=mysmartlogon,DC=com 2,Reset Password…,\\gpaa\packages\resetpw.bat  2022-12-04 13:56:29Z
+ 10 Point(s)

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.

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

Details:

The detail can be found in Admin Groups

AccountCreationLastChanged
wrongaccount8 2016-03-28 10:40:52Z 2016-03-28 12:40:52Z
tset ☺☻♥♦♣♠•◘○◙♂♀♪♫☼ 2019-10-26 19:20:02Z Never
wrongAccount5 2015-06-26 15:47:18Z Never
wrongAccount1 2015-06-26 10:20:33Z Never
testitb1 2019-04-06 11:31:38Z 2019-04-06 13:31:38Z
test2 2019-03-23 07:19:15Z 2019-03-23 08:19:15Z
+ 10 Point(s)

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:

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

Details:

The detail can be found in Admin Groups

+ 5 Point(s)

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.

Points:

5 points if present

Documentation:

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

Details:
Member
CN=BlueHat,CN=Users,DC=test,DC=mysmartlogon,DC=com
+ 5 Point(s)

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.

Points:

5 points if present

Documentation:

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

Details:
Missing
Domain Administrators
Informative rule

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

Details:

The detail can be found in Admin Groups

GroupMembers
Account Operators 1
Informative rule

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

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

Details:

The detail can be found in Admin Groups

050100

Trusts : 100 /100

It is about links between two Active Directories

+ 50 Point(s)

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:

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

Details:

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

+ 50 Point(s)

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

Details:

The detail can be found in Trusts section

Trust
mil
+ 20 Point(s)

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

Details:

The detail can be found in Trusts section

Trust
mil
test4.mysmartlogon.com
+ 10 Point(s)

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

Points:

10 points if present

Documentation:

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

Details:

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

Domain
S-1-5-18
test.mysmartlogon.com
+ 5 Point(s)

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

+ 1 Point(s)

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.

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

Details:
TrustReason
test4.mysmartlogon.com Not Configured
050100

Anomalies : 100 /100

It is about specific security control points

+ 80 Point(s)

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
[MITRE]T1552.006 Unsecured Credentials: Group Policy Preferences
[FR]ANSSI CERTFR-2015-ACT-046

Details:

The detail can be found in the Obfuscated Passwords

GPOloginpassword
WEF test ssss dddd
test nfc 2 administrator vletoux
test nfc 2 adiant vletoux
test nfc 2 test test
+ 50 Point(s)

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

Details:

The detail can be found in Krbtgt

+ 30 Point(s)

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. Internally the hash of this password is used to sign the user's Kerberos tickets, making this account vulnerable to Silver ticket attacks. The rule is triggered 90 days after the last change of the attribute unicodePwd. This value is collected using the replication metadata of the attribute 589914

Advised solution:

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

Points:

30 points if present

Documentation:

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

Details:

The detail can be found in Smart Card and Password

+ 15 Point(s)

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

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

Details:

The detail can be found in Certificate Templates

Name
CopyofCopyofEnrollmentAgent2
CopyofCopyofCopyofCopyofEnrollmentAgen4
+ 15 Point(s)

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.

Points:

15 points if present

Documentation:

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

+ 15 Point(s)

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

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

Details:

The detail can be found in Certificate Templates

Name
Copy of Enrollment Agent
+ 15 Point(s)

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

Details:

The detail can be found in Backup

+ 15 Point(s)

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.

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
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space
[FR]ANSSI - Weak or vulnerable certificates (vuln1_certificates_vuln)1

Details:

The detail can be found in Certificates

SourceSubjectExpires
GPO:Default Domain Controllers Policy;Machine CN=localhost 2018-10-16 21:46:10Z
+ 15 Point(s)

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)

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

Details:

The detail can be found in Certificate Templates

Name
SubCA
+ 15 Point(s)

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

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
[MITRE]T1557 Man-in-the-Middle
[FR]ANSSI - Misconfigured DNS zones (vuln1_dnszone_bad_prop)1

Details:
Zone
test.mysmartlogon.com
+ 15 Point(s)

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.

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

Details:

The detail can be found in Certificate Templates

Name
SubCA
SmartcardLogonforKSP
+ 15 Point(s)

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

Details:

The detail can be found in the AdminSDHolder User List

+ 10 Point(s)

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.

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

Details:

The detail can be found in Domain controllers

DCProtocol
WIN-PGAHI2ECI8E Ssl2
WIN-PGAHI2ECI8E Ssl3
+ 10 Point(s)

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.

Points:

10 points if present

Documentation:

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

Details:

The detail can be found in Audit settings
The table below shows the settings that were not found as configured in a GPO for a given domain controller.

TypeAuditProblemRationaleDomain controller
Advanced Policy Change / Authentication Policy Change No GPO check for audit success Collect events 4713, 4716, 4739, 4867, to track trust modifications ADIANT-A7B9AAC6
Advanced Account Management / Computer Account Management No GPO check for audit success Collect events 4741, 4742 to track computer changes ADIANT-A7B9AAC6
Advanced Detailed Tracking / DPAPI Activity No GPO check for audit success Collect event 4692 to track the export of DPAPI backup key ADIANT-A7B9AAC6
Advanced Account Logon / Kerberos Authentication Service No GPO check for audit success Collect events 4768, 4771 for kerberos authentication ADIANT-A7B9AAC6
Advanced Account Logon / Kerberos Service Ticket Operations No GPO check for audit success Collect events 4769 for kerberos authentication ADIANT-A7B9AAC6
Advanced Logon/Logoff / Logoff No GPO check for audit success Collect events 4634 for account logoff ADIANT-A7B9AAC6
Advanced Detailed Tracking / Process Creation No GPO check for audit success Collect event 4688 to get the history of executed programs ADIANT-A7B9AAC6
Advanced Account Management / Security Group Management No GPO check for audit success Collect events 4728, 4732, 4756 for group membership change ADIANT-A7B9AAC6
Advanced System / Security System Extension No GPO check for audit success Collect events 4610, 4697 to track lsass security packages and services ADIANT-A7B9AAC6
Advanced Privilege Use / Sensitive Privilege Use No GPO check for audit success Collect events 4672, 4673, 4674 for privileges tracking such as the debug one ADIANT-A7B9AAC6
Advanced Logon/Logoff / Special Logon No GPO check for audit success Collect event 4964 for special group attributed at logon ADIANT-A7B9AAC6
Advanced Account Management / User Account Management No GPO check for audit success Collect events 4720,22,23,38,65,66,80,94 for user account mamangement ADIANT-A7B9AAC6
+ 10 Point(s)

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

Details:

The detail can be found in Domain controllers and Null Session

Domain controller
WIN-PGAHI2ECI8E
+ 10 Point(s)

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

Details:

The detail can be found in Password policies

GPO
Test GPO site
Default Domain Policy
Default Domain Controllers Policy
PSO:test
PSO:test2
+ 10 Point(s)

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
[MITRE]T1110.002 Brute Force: Password Cracking
[FR]ANSSI - Accounts with passwords stored using reversible encryption (vuln3_reversible_password)3

Details:

The detail can be found in Security settings

GPO
PSO:test2
+ 5 Point(s)

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]
[MITRE]T1110.002 Brute Force: Password Cracking
[US]STIG V-3379 - The system is configured to store the LAN Manager hash of the password in the SAM.

Details:

The detail can be found in Security settings

GPOSetting
Default Domain Policy NoLMHash
+ 5 Point(s)

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.

Points:

5 points if present

Documentation:


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

Details:

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

GPOKeyRequireIntegrityRequireMutualAuthenticationRequirePrivacy
Default Domain Controllers Policy \\*\SYSVOL Disabled Disabled Disabled
No GPO Found NETLOGON Not Set Not Set Not Set
+ 5 Point(s)

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
[MITRE]T1110.003 Brute Force: Password Spraying
[US]STIG V-8547 - The Anonymous Logon and Everyone groups must not be members of the Pre-Windows 2000 Compatible Access group.
[FR]ANSSI - The "Pre - Windows 2000 Compatible Access" group includes "Anonymous" (vuln2_compatible_2000_anonymous)2

+ 5 Point(s)

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.

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

Details:

The detail can be found in Security settings

GPO
Default Domain Policy
+ 5 Point(s)

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.

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

Details:

The detail can be found in LAPS

+ 2 Point(s)

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.

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

+ 1 Point(s)

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

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

Details:

The detail can be found in Certificates

SourceSubjectModuleExpires
GPO:Default Domain Policy;Machine CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI 2048 2041-09-15 09:08:21Z
NTLMStore CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI 2048 2041-09-15 09:08:21Z
+ 1 Point(s)

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

Details:

The detail can be found in Certificates

GPOSubject
GPO:Default Domain Policy;Machine SERIALNUMBER=200804, CN=Foreigner CA, C=BE
GPO:Default Domain Policy;Machine CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
GPO:Default Domain Policy;Machine CN=COMODO Code Signing CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
NTLMStore CN=COMODO Code Signing CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
NTLMStore CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
NTLMStore CN=COMODO Code Signing CA, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
Informative rule

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.

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

Details:

The detail can be found in Security settings

Informative rule

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.

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

Informative rule

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

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

Details:
SettingPositionValue
LDAPAddAuthZVerifications 28th Not Set
LDAPOwnerModify 29th Not Set
Informative rule

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).
[MITRE]T1600.001 Weaken Encryption: Reduce Key Space
[FR]ANSSI - Weak or vulnerable certificates (vuln3_certificates_vuln)3

Details:

The detail can be found in Certificates

GPOSubject
GPO:Default Domain Policy;Machine CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
GPO:Default Domain Policy;Machine CN=Belgium Root CA2, C=BE
GPO:Default Domain Policy;Machine CN=MaskTech CSCA, OU=Test Division, O=MaskTech GmbH, C=DE
GPO:Default Domain Policy;Machine CN=CA, DC=test, DC=mysmartlogon, DC=com
GPO:Default Domain Policy;Machine CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI
NTLMStore CN=CA, DC=test, DC=mysmartlogon, DC=com
NTLMStore CN=MaskTech CSCA, OU=Test Division, O=MaskTech GmbH, C=DE
NTLMStore CN=Belgium Root CA2, C=BE
NTLMStore CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI
NTLMStore CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
NTLMStore CN=CA, DC=test, DC=mysmartlogon, DC=com
Informative rule

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

Details:

The schema version is indicated in Domain Information

Informative rule

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/
[MITRE]T1552 Unsecured Credentials
[FR]ANSSI - Accounts with passwords stored using reversible encryption (vuln3_reversible_password)3

Details:

The detail can be found in Unix Passwords

User
wrongaccount8
Informative rule

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.

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

Details:
DNSZone
test.mysmartlogon.com
Informative rule

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.

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controller
WIN-PGAHI2ECI8E
Informative rule

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Security settings

Informative rule

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

Details:

The detail can be found in Password Policies

This section shows the main technical characteristics of the domain.

DomainNetbios NameDomain Functional LevelForest Functional LevelCreation dateDC countSchema versionRecycle Bin enabled
test.mysmartlogon.comTESTWindows Server 2008 R2Windows Server 2008 R22012-03-03 18:12:40Z2Windows Server 2008 R2TRUE

Azure AD Configuration

No Azure AD configuration has been found in this domain

This section gives information about the user accounts stored in the Active Directory

Honey Pot

A honey pot has been configured. It is used to generate fake security issues that are heavily monitored and that a hacker will spot using security tools like PingCastle. By enabling this feature, all the accounts listed below will not be evaluated with PingCastle rules.

[3]
NameCreationLast logonDistinguished name
ADIANT-VIRTUAL-$2019-01-27 12:57:02Z2019-01-27 13:57:02ZCN=ADIANT-VIRTUAL-,CN=Computers,DC=test,DC=mysmartlogon,DC=com
HoneyPot2020-01-18 10:07:42ZNeverCN=Honey Pot,CN=Users,DC=test,DC=mysmartlogon,DC=com
HoneyPotInexistantAccess DeniedNever

Account analysis

Nb User AccountsNb Enabled ?Nb Disabled ?Nb Active ?Nb Inactive ?Nb Locked ?Nb pwd never Expire ?Nb SidHistory ?Nb Bad PrimaryGroup ?Nb Password not Req. ?Nb Des enabled. ?Nb unconstrained delegations ?Nb Reversible password ?
2421331808302000
[18]
NameCreationLast logonDistinguished name
1234567892017-11-15 13:47:44ZNeverCN=tata yoyo.123456789,CN=Users,DC=test,DC=mysmartlogon,DC=com
BlueHat2018-01-19 15:23:37ZNeverCN=BlueHat,CN=Users,DC=test,DC=mysmartlogon,DC=com
Guest2012-03-03 18:13:00Z2022-01-13 18:31:32ZCN=Guest,CN=Users,DC=test,DC=mysmartlogon,DC=com
HINSON2014-11-30 16:02:50ZNeverCN=Kimberly Hinson,CN=Users,DC=test,DC=mysmartlogon,DC=com
min2014-06-21 21:19:29Z2014-07-03 21:24:07ZCN=min,CN=Users,DC=test,DC=mysmartlogon,DC=com
test2013-03-31 11:33:16Z2022-03-14 11:52:36ZCN=test,CN=Users,DC=test,DC=mysmartlogon,DC=com
test22019-03-23 07:19:15Z2020-01-12 14:26:14ZCN=test2,CN=Users,DC=test,DC=mysmartlogon,DC=com
testitb12019-04-06 11:31:38Z2019-04-06 13:33:30ZCN=testitb,CN=Builtin,DC=test,DC=mysmartlogon,DC=com
tset ☺☻♥♦♣♠•◘○◙♂♀♪♫☼2019-10-26 19:20:02ZNeverCN=test ☺☻♥♦♣♠•◘○◙♂♀♪♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongAccount12015-06-26 10:20:33ZNeverCN=wrongAccount1,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongaccount102018-08-20 14:22:43ZNeverCN=wrongaccount10,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
wrongAccount22015-06-26 10:20:48ZNeverCN=wrongAccount2,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongaccount32015-06-26 11:13:15ZNeverCN=wrongaccount3,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongAccount52015-06-26 15:47:18ZNeverCN=wrongAccount5,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
wrongAccount62015-06-26 15:47:35ZNeverCN=wrongAccount6,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
wrongAccount72015-06-27 07:26:05Z2015-06-27 09:27:23ZCN=wrongAccount7,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
wrongaccount82016-03-28 10:40:52ZNeverCN=wrongaccount8,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongaccount92016-03-30 13:02:35ZNeverCN=wrongaccount9,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
[8]
NameCreationLast logonDistinguished name
Adiant2012-03-03 18:13:00Z2023-04-16 18:06:28ZCN=Adiant,CN=Users,DC=test,DC=mysmartlogon,DC=com
Administrator2012-03-03 18:13:00Z2020-03-02 18:58:06ZCN=Administrator,CN=Users,DC=test,DC=mysmartlogon,DC=com
Guest2012-03-03 18:13:00Z2022-01-13 18:31:32ZCN=Guest,CN=Users,DC=test,DC=mysmartlogon,DC=com
HINSON2014-11-30 16:02:50ZNeverCN=Kimberly Hinson,CN=Users,DC=test,DC=mysmartlogon,DC=com
min2014-06-21 21:19:29Z2014-07-03 21:24:07ZCN=min,CN=Users,DC=test,DC=mysmartlogon,DC=com
test2013-03-31 11:33:16Z2022-03-14 11:52:36ZCN=test,CN=Users,DC=test,DC=mysmartlogon,DC=com
test22019-03-23 07:19:15Z2020-01-12 14:26:14ZCN=test2,CN=Users,DC=test,DC=mysmartlogon,DC=com
testitb12019-04-06 11:31:38Z2019-04-06 13:33:30ZCN=testitb,CN=Builtin,DC=test,DC=mysmartlogon,DC=com
[3]
NameCreationLast logonDistinguished name
BlueHat2018-01-19 15:23:37ZNeverCN=BlueHat,CN=Users,DC=test,DC=mysmartlogon,DC=com
test2013-03-31 11:33:16Z2022-03-14 11:52:36ZCN=test,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongaccount82016-03-28 10:40:52ZNeverCN=wrongaccount8,CN=Users,DC=test,DC=mysmartlogon,DC=com
[2]
NameCreationLast logonDistinguished name
BlueHat2018-01-19 15:23:37ZNeverCN=BlueHat,CN=Users,DC=test,DC=mysmartlogon,DC=com
Guest2012-03-03 18:13:00Z2022-01-13 18:31:32ZCN=Guest,CN=Users,DC=test,DC=mysmartlogon,DC=com
[1]
NameCreationLast logonDistinguished name
wrongaccount82016-03-28 10:40:52ZNeverCN=wrongaccount8,CN=Users,DC=test,DC=mysmartlogon,DC=com

Password Age Distribution

Here is the distribution where the password has been changed for the last time. Only enabled user accounts are analyzed (no guest account for example).

0-30 days30-60 days60-90 days90-120 days120-150 days150-180 days180-210 days210-240 days240-270 days270-300 days300-330 days330-360 days360-390 days390-420 days420-450 days450-480 days480-510 days510-540 days540-570 days570-600 days600-630 days630-660 days660-690 days690-720 days720-750 days750-780 days780-810 days810-840 days840-870 days870-900 days900-930 days930-960 days960-990 days990-1020 days1020-1050 days1050-1080 daysOther0246810

SID History

SID History from domainFirst date seen ?Last date seen ?CountDangerous SID Found
S-1-5-182013-03-31 11:33:16Z2013-03-31 11:33:16Z1True
test.mysmartlogon.com2016-03-28 10:40:52Z2018-01-19 15:23:37Z2True

Account analysis

This section gives information about the computer accounts stored in the Active Directory

Nb Computer AccountsNb Enabled ?Nb Disabled ?Nb Active ?Nb Inactive ?Nb SidHistory ?Nb Bad PrimaryGroup ?Nb unconstrained delegations ?Nb Reversible password ?
990180110
[8]
NameCreationLast logonDistinguished name
ADIANT-2CC70D66$2013-04-01 09:32:22Z2013-04-01 11:32:26ZCN=ADIANT-2CC70D66,CN=Computers,DC=test,DC=mysmartlogon,DC=com
ADIANT-A7B9AAC6$2013-04-01 10:10:33Z2018-11-09 07:29:04ZCN=ADIANT-A7B9AAC6,CN=Computers,DC=test,DC=mysmartlogon,DC=com
CREATOR$2021-05-13 07:03:09ZNeverCN=Creator$,CN=Computers,DC=test,DC=mysmartlogon,DC=com
DESKTOP-RLP9BES$2019-03-23 06:38:12Z2020-06-16 17:46:39ZCN=DESKTOP-RLP9BES,OU=Test LAPS,DC=test,DC=mysmartlogon,DC=com
TEST$2019-01-27 09:40:38Z2019-01-27 10:40:41ZCN=TEST,CN=Computers,DC=test,DC=mysmartlogon,DC=com
WIN-1MLHM2RAF4U$2012-03-03 18:24:33Z2020-05-21 15:17:08ZCN=WIN-1MLHM2RAF4U,CN=Computers,DC=test,DC=mysmartlogon,DC=com
WIN-3RC77Q4T0SP$2019-03-22 21:30:21Z2019-12-01 13:01:52ZCN=WIN-3RC77Q4T0SP,CN=Computers,DC=test,DC=mysmartlogon,DC=com
WINDOWS7X86$2012-03-03 22:07:05Z2016-09-15 23:54:27ZCN=WINDOWS7X86,CN=Computers,DC=test,DC=mysmartlogon,DC=com
[2]
NameCreationLast logonDistinguished name
CREATOR$2021-05-13 07:03:09ZNeverCN=Creator$,CN=Computers,DC=test,DC=mysmartlogon,DC=com
TEST$2019-01-27 09:40:38Z2019-01-27 10:40:41ZCN=TEST,CN=Computers,DC=test,DC=mysmartlogon,DC=com
[1]
NameCreationLast logonDistinguished name
ADIANT-A7B9AAC6$2013-04-01 10:10:33Z2018-11-09 07:29:04ZCN=ADIANT-A7B9AAC6,CN=Computers,DC=test,DC=mysmartlogon,DC=com
[2]
NameCreationLast logonDistinguished name
TEST$2019-01-27 09:40:38Z2019-01-27 10:40:41ZCN=TEST,CN=Computers,DC=test,DC=mysmartlogon,DC=com
WIN-PGAHI2ECI8E$2012-03-03 18:17:15Z2023-04-16 18:02:26ZCN=WIN-PGAHI2ECI8E,OU=Domain Controllers,DC=test,DC=mysmartlogon,DC=com
[2]
NameCreationLast logonDistinguished name
ADIANT-2CC70D66$2013-04-01 09:32:22Z2013-04-01 11:32:26ZCN=ADIANT-2CC70D66,CN=Computers,DC=test,DC=mysmartlogon,DC=com
ADIANT-A7B9AAC6$2013-04-01 10:10:33Z2018-11-09 07:29:04ZCN=ADIANT-A7B9AAC6,CN=Computers,DC=test,DC=mysmartlogon,DC=com
[1]
NameCreationLast logonDistinguished name
WIN-PGAHI2ECI8E$2012-03-03 18:17:15Z2023-04-16 18:02:26ZCN=WIN-PGAHI2ECI8E,OU=Domain Controllers,DC=test,DC=mysmartlogon,DC=com

Operating Systems

If you need to find the computers running a specific OS, we advise to use PingCastle.exe and the export / computers feature available from the main menu. Indeed the computer details are not included in the report for performance issues. Doing this will impact significantly the report size and the time to load the report.

Operating SystemNb OSNb Enabled ?Nb Disabled ?Nb Active ?Nb Inactive ?Nb SidHistory ?Nb Bad PrimaryGroup ?Nb unconstrained delegations ?Nb Reversible password ?
OperatingSystem not set220020000
Ubuntu Desktop Linux000000000
Windows Server 2008 R2110100010
Windows 7330030000
Windows XP220020100
Windows 10 1809110010000

Domain controllers

Here is a specific zoom related to the Active Directory servers: the domain controllers.

[2]
Domain controllerOperating SystemCreation Date ?Startup TimeUptimeOwner ?Null sessions ?SMB v1 ?Remote spooler ?FSMO role ?WebDAV ?
WIN-PGAHI2ECI8EWindows 20082012-03-03 18:17:15Z2022-05-18 08:39:36Z341 daysTEST\Domain AdminsYESYESNOPDC,
RID pool manager,
Infrastructure master,
Schema master,
Domain naming Master
YES
ADIANT-A7B9AAC6Windows XP2013-04-01 10:10:33ZInactive?TEST\AdministratorNONONONO

LAPS Analysis

Here is the distribution of the LAPS password fresshness.

0-30 days30-60 days60-90 days90-120 days120-150 days150-180 days180-210 days210-240 days240-270 days270-300 days300-330 days330-360 days360-390 days390-420 days420-450 days450-480 days480-510 days510-540 days540-570 days570-600 days600-630 days630-660 days660-690 days690-720 days720-750 days750-780 days780-810 days810-840 days840-870 days870-900 days900-930 days930-960 days960-990 days990-1020 days1020-1050 days1050-1080 daysOther0246810

Here is the application of LAPS

Enabled computers with LAPS (2) over all enabled computers (7)
Enabled workstations with LAPS (1) over all enabled workstations (6)
Enabled servers with LAPS (1) over all enabled servers (1)
Operating SystemNumber of EnabledNumber of LAPS installedRatio (%)
Windows Server 2008 R211100
Windows 7300
Windows XP200
Windows 10 180911100

Groups

This section is focused on the groups which are critical for admin activities. If the report has been saved which the full details, each group can be zoomed with its members. If it is not the case, for privacy reasons, only general statistics are available.

Group NameNb Admins ?Nb Enabled ?Nb Disabled ?Nb Inactive ?Nb PWd never expire ?Nb Smart Card required ?Nb Service accounts ?Nb can be delegated ?Nb external users ?Nb protected users ?
Account Operators1101000100
Administrators6514211400
Backup Operators0000000000
Certificate Operators0000000000
Certificate Publishers0000000000
Dns Admins1101000100
Domain Administrators5413211300
Enterprise Administrators1101100000
Print Operators3303300300
Replicator0000000000
Schema Administrators2201201100
Server Operators0000000000
[10]
SamAccountName ?Enabled ?Active ?Pwd never Expired ?Locked ?Smart Card required ?Service account ?Flag Cannot be delegated present ?Creation date ?Last login ?Password last set ?In Protected Users ?Distinguished name ?
AdiantYESYESYESNONOYESNO2012-03-03 18:13:00Z2023-04-16 18:06:28Z2020-10-04 13:47:50ZNOCN=Adiant,CN=Users,DC=test,DC=mysmartlogon,DC=com
AdministratorYESNOYESNONONOYES2012-03-03 18:13:00Z2020-03-02 18:58:06Z2023-03-25 16:09:39ZNOCN=Administrator,CN=Users,DC=test,DC=mysmartlogon,DC=com
testYESNOYESNONONONO2013-03-31 11:33:16Z2022-03-14 11:52:36Z2020-06-15 11:40:01ZNOCN=test,CN=Users,DC=test,DC=mysmartlogon,DC=com
test2YESNOYESNONONONO2019-03-23 07:19:15Z2020-01-12 14:26:14Z2019-03-23 08:19:15ZNOCN=test2,CN=Users,DC=test,DC=mysmartlogon,DC=com
teste (NONONONONONOYES2017-01-09 18:07:43ZNot set1601-01-01 01:00:00ZNOCN=New Object with (dsg,CN=Users,DC=test,DC=mysmartlogon,DC=com
testitb1YESNOYESNONONONO2019-04-06 11:31:38Z2019-04-06 13:33:30Z2019-04-06 13:31:38ZNOCN=testitb,CN=Builtin,DC=test,DC=mysmartlogon,DC=com
tset ☺☻♥♦♣♠•◘○◙♂♀♪♫☼YESNONONONONONO2019-10-26 19:20:02ZNot set1601-01-01 01:00:00ZNOCN=test ☺☻♥♦♣♠•◘○◙♂♀♪♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongAccount1YESNONONONONONO2015-06-26 10:20:33ZNot set1601-01-01 01:00:00ZNOCN=wrongAccount1,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongAccount5YESNONONOYESNONO2015-06-26 15:47:18ZNot set1601-01-01 01:00:00ZNOCN=wrongAccount5,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
wrongaccount8YESNONONONONONO2016-03-28 10:40:52ZNot set2016-03-28 12:40:52ZNOCN=wrongaccount8,CN=Users,DC=test,DC=mysmartlogon,DC=com

Last Logon Distribution

Here is the distribution of the last logon of privileged users. Only enabled accounts are analyzed.

0-30 days30-60 days60-90 days90-120 days120-150 days150-180 days180-210 days210-240 days240-270 days270-300 days300-330 days330-360 days360-390 days390-420 days420-450 days450-480 days480-510 days510-540 days540-570 days570-600 days600-630 days630-660 days660-690 days690-720 days720-750 days750-780 days780-810 days810-840 days840-870 days870-900 days900-930 days930-960 days960-990 days990-1020 days1020-1050 days1050-1080 daysOther0246810

Password Age Distribution

Here is the distribution of the password age for privileged users. Only enabled accounts are analyzed.

0-30 days30-60 days60-90 days90-120 days120-150 days150-180 days180-210 days210-240 days240-270 days270-300 days300-330 days330-360 days360-390 days390-420 days420-450 days450-480 days480-510 days510-540 days540-570 days570-600 days600-630 days630-660 days660-690 days690-720 days720-750 days750-780 days780-810 days810-840 days840-870 days870-900 days900-930 days930-960 days960-990 days990-1020 days1020-1050 days1050-1080 daysOther0246810

Delegations

Each specific rights defined for Organizational Unit (OU) are listed below.

[12]
DistinguishedNameAccountRight
DC=testEveryoneGenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
DC=testTEST\Domain ControllersEXT_RIGHT_REPLICATION_GET_CHANGES_ALL
CN=MicrosoftDNS,CN=SystemTEST\DnsAdminsGenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
CN=MicrosoftDNS,CN=SystemTEST\wrongaccount3GenericWrite, DSSelf, Write all prop
CN=RAS and IAS Servers Access Check,CN=SystemTEST\RAS and IAS ServersGenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
CN=WMIPolicy,CN=SystemTEST\Group Policy Creator OwnersGenericWrite, DSSelf, Write all prop
CN=SOM,CN=WMIPolicy,CN=SystemTEST\Group Policy Creator OwnersGenericWrite, DSSelf, Write all prop
CN=UsersS-1-5-21-4005144719-3948538632-2546531719-1115EXT_RIGHT_FORCE_CHANGE_PWD
OU=TestOUTEST\adiantGenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
OU=TestOUTEST\wrongAccount6GenericAll, GenericWrite, WriteDacl, WriteOwner
OU=TestOUTEST\wrongAccount7EXT_RIGHT_FORCE_CHANGE_PWD
OU=TestOUTEST\wrongaccount9EXT_RIGHT_FORCE_CHANGE_PWD

In particular for AD database access (DCSync, AADConnect, ...).

[1]
DistinguishedNameAccountRight
DC=testTEST\Domain ControllersEXT_RIGHT_REPLICATION_GET_CHANGES_ALL

This section focuses on permissions issues that can be exploited to take control of the domain.
This is an advanced section that should be examined after having looked at the Admin Groups section.

Foreign domain involved

This analysis focuses on accounts found in control path and located in other domains.

No operative link with other domains has been found.

Indirect links

This part tries to summarize in a single table if major issues have been found.
Focus on finding critical objects such as the Everyone group then try to decrease the number of objects having indirect access.
The detail is displayed below.

Priority to remediate ?Critical Object Found ?Number of objects with Indirect ?Max number of indirect numbers ?Max ratio ?
CriticalYES64100
HighNO000
MediumYES21100
OtherYES130

Admin groups

If the report has been saved which the full details, each object can be zoomed with its full detail. If it is not the case, for privacy reasons, only general statistics are available.

Group or user account ?Priority ?Users member ?Computer member of the group ?Indirect control ?Unresolved members ?Links ?Detail ?
Account OperatorsHigh1 (Details)000NoneAnalysis
AdministratorCritical1 (Details)0NoneAnalysis
AdministratorsCritical6 (Details)03 (Details)0NoneAnalysis
Backup OperatorsHigh0000NoneAnalysis
Certificate OperatorsMedium0000NoneAnalysis
Certificate PublishersOther01 (Details)3 including EVERYONE (Details)0NoneAnalysis
Dns AdminsMedium1 (Details)000NoneAnalysis
Domain AdministratorsCritical5 (Details)03 (Details)0NoneAnalysis
Enterprise AdministratorsCritical1 (Details)01 (Details)0NoneAnalysis
Print OperatorsMedium3 (Details)000NoneAnalysis
ReplicatorMedium0000NoneAnalysis
Schema AdministratorsCritical2 (Details)02 (Details)0NoneAnalysis
Server OperatorsHigh0000NoneAnalysis

Critical Infrastructure

If the report has been saved which the full details, each object can be zoomed with its full detail. If it is not the case, for privacy reasons, only general statistics are available.

Group or user account ?Priority ?Users member ?Computer member of the group ?Indirect control ?Unresolved members ?Links ?Detail ?
Builtin OUMedium00NoneAnalysis
Certificate storeMedium00NoneAnalysis
Computers containerMedium00NoneAnalysis
Domain ControllersCritical02 (Details)4 including EVERYONE (Details)0NoneAnalysis
Domain RootMedium1 including EVERYONE (Details)0NoneAnalysis
Enterprise Read Only Domain ControllersOther0000NoneAnalysis
Group Policy Creator OwnersMedium1 (Details)01 (Details)0NoneAnalysis
Krbtgt accountMedium00NoneAnalysis
Read Only Domain ControllersMedium0000NoneAnalysis
Users containerMedium00NoneAnalysis

This section focuses on the relations that this domain has with other domains

Discovered Domains

This part displays the direct links that this domain has with other domains.

Trust PartnerTypeAttributDirection ?SID Filtering active ?TGT Delegation ?Creation ?Is Active ? ?Algorithm ?
mil ?MITNon-TransitiveOutboundNoNot applicable2014-06-09 12:49:20ZFALSEDefault (RC4)
test4.mysmartlogon.com ?UplevelForest TrustInboundNot applicableNo2019-04-06 21:53:36ZFALSEDefault (RC4)

Reachable Domains

These are the domains that PingCastle was able to detect but which is not releated to direct trusts. It may be children of a forest or bastions.

Reachable domainDiscovered usingNetbiosCreation date
PKI

Certificates

This detects trusted certificates which can be used in man in the middle attacks, or which can issue smart card logon certificates

Number of trusted certificates: 19

[19]
SourceStoreSubjectIssuerNotBeforeNotAfterModule sizeSignature AlgSC Logon
GPO:Default Domain Policy;MachineRootCN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SECN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE2000-05-30 12:48:38Z2020-05-30 12:48:38Z2048sha1RSAFalse
GPO:Default Domain Policy;MachineRootCN=Belgium Root CA2, C=BECN=Belgium Root CA2, C=BE2007-10-04 12:00:00Z2021-12-15 09:00:00Z2048sha1RSAFalse
GPO:Default Domain Policy;MachineRootCN=MaskTech CSCA, OU=Test Division, O=MaskTech GmbH, C=DECN=MaskTech CSCA, OU=Test Division, O=MaskTech GmbH, C=DE2014-02-13 15:30:41Z2019-01-16 15:30:41Z3072sha1RSAFalse
GPO:Default Domain Policy;MachineRootCN=CA, DC=test, DC=mysmartlogon, DC=comCN=CA, DC=test, DC=mysmartlogon, DC=com2015-10-03 09:34:06Z2030-10-02 09:44:04Z2048sha1RSAFalse
GPO:Default Domain Policy;MachineRootCN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKICN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI2014-05-01 09:08:21Z2041-09-15 09:08:21Z2048sha1RSAFalse
GPO:Default Domain Policy;MachineCASERIALNUMBER=200804, CN=Foreigner CA, C=BECN=Belgium Root CA2, C=BE2007-10-04 14:00:00Z2014-06-04 14:00:00Z2048sha1RSAFalse
GPO:Default Domain Policy;MachineCACN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=USCN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE2005-06-07 10:09:10Z2020-05-30 12:48:38Z2048sha1RSAFalse
GPO:Default Domain Policy;MachineCACN=COMODO Code Signing CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GBCN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US2011-08-24 02:00:00Z2020-05-30 12:48:38Z2048sha1RSAFalse
GPO:Default Domain Controllers Policy;MachineRootCN=localhostCN=localhost2017-10-16 21:46:28Z2018-10-16 21:46:28Z2048sha256RSAFalse
GPO:Default Domain Controllers Policy;MachineRootCN=localhostCN=localhost2017-10-16 21:46:10Z2018-10-16 21:46:10Z2056sha256RSAFalse
Enterprise NTAuth ?NTLMStoreCN=CA, DC=test, DC=mysmartlogon, DC=comCN=CA, DC=test, DC=mysmartlogon, DC=com2015-10-03 09:34:06Z2030-10-02 09:44:04Z2048sha1RSAFalse
Enterprise NTAuth ?NTLMStoreCN=MaskTech CSCA, OU=Test Division, O=MaskTech GmbH, C=DECN=MaskTech CSCA, OU=Test Division, O=MaskTech GmbH, C=DE2014-02-13 15:30:41Z2019-01-16 15:30:41Z3072sha1RSAFalse
Enterprise NTAuth ?NTLMStoreCN=Belgium Root CA2, C=BECN=Belgium Root CA2, C=BE2007-10-04 12:00:00Z2021-12-15 09:00:00Z2048sha1RSAFalse
Enterprise NTAuth ?NTLMStoreCN=COMODO Code Signing CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GBCN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US2011-08-24 02:00:00Z2020-05-30 12:48:38Z2048sha1RSAFalse
Enterprise NTAuth ?NTLMStoreCN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKICN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI2014-05-01 09:08:21Z2041-09-15 09:08:21Z2048sha1RSAFalse
Enterprise NTAuth ?NTLMStoreCN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SECN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE2000-05-30 12:48:38Z2020-05-30 12:48:38Z2048sha1RSAFalse
Enterprise NTAuth ?NTLMStoreCN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=USCN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE2005-06-07 10:09:10Z2020-05-30 12:48:38Z2048sha1RSAFalse
Enterprise NTAuth ?NTLMStoreCN=COMODO Code Signing CA, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GBCN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US2011-04-27 02:00:00Z2020-05-30 12:48:38Z2048sha1RSAFalse
Enterprise NTAuth ?NTLMStoreCN=CA, DC=test, DC=mysmartlogon, DC=comCN=CA, DC=test, DC=mysmartlogon, DC=com2012-03-03 19:21:37Z2027-03-03 19:31:35Z2048sha1RSAFalse

Certificate Templates

This section lists certificate templates which can be used to generate a certificate. A misconfiguration can allow an attacker to create its own certificate and use it to impersonate other users

Number of certificate templates: 21

[21]
NameDestinationManager approval ?Enrollee can supply subject ?Issuance requirements ?Vulnerable ACL ?Everyone can enroll ?Agent template ?Any purpose ?For Authentication ?Flag No Security ?
User ?UserNONONONOYESNONOYESNO
SmartcardLogon ?UserNONONONOYESNONOYESNO
EFS ?UserNONONONOYESNONONONO
Administrator ?UserNONONONONONONOYESNO
EFSRecovery ?UserNONONONONONONONONO
EnrollmentAgent ?UserNONONONONOYESNONONO
MachineEnrollmentAgent ?ComputerNONONONONOYESNONONO
Machine ?ComputerNONONONOYESNONOYESNO
DomainController ?ComputerNONONONONONONOYESNO
WebServer ?ComputerNOYESNONONONONONONO
SubCA ?ComputerNOYESNONOYESNOYESYESNO
CAExchange ?ComputerNOYESNONOYESNONONONO
DomainControllerAuthentication ?ComputerNONONONONONONOYESNO
DirectoryEmailReplication ?ComputerNONONONONONONONONO
DomainControllerAuthenticationECC ?ComputerNONONONONONONOYESNO
Userwithapproval(seePending) ?UserYESNONONOYESNONOYESNO
UserTest ?UserNONONONOYESNONOYESNO
SmartcardLogonforKSP ?UserNOYESNONOYESNONOYESNO
Copy of Enrollment Agent ?UserNOYESNONOYESYESNONONO
CopyofCopyofEnrollmentAgent2 ?UserNONONOYESNOYESNONONO
CopyofCopyofCopyofCopyofEnrollmentAgen4 ?UserNONONOYESNOYESNONONO

The delegations for certificate templates are listed below.

[27]
DistinguishedNameAccountRight
CN=CAExchange,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationAuthenticated UsersEnroll
CN=Copy of Enrollment Agent,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationAuthenticated UsersEnroll
CN=Copy of Enrollment Agent,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\adiantGenericWrite, WriteDacl, WriteOwner, DSSelf, Write all prop
CN=CopyofCopyofCopyofCopyofEnrollmentAgen4,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationAuthenticated UsersGenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
CN=CopyofCopyofCopyofCopyofEnrollmentAgen4,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\adiantGenericWrite, WriteDacl, WriteOwner, DSSelf, Write all prop
CN=CopyofCopyofEnrollmentAgent2,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationAuthenticated UsersGenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
CN=CopyofCopyofEnrollmentAgent2,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\adiantGenericWrite, WriteDacl, WriteOwner, DSSelf, Write all prop
CN=DirectoryEmailReplication,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\Domain ControllersEnroll
CN=DirectoryEmailReplication,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\Enterprise Read-only Domain ControllersEnroll
CN=DomainController,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\Domain ControllersEnroll
CN=DomainController,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\Enterprise Read-only Domain ControllersEnroll
CN=DomainControllerAuthentication,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\Domain ControllersEnroll
CN=DomainControllerAuthentication,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\Enterprise Read-only Domain ControllersEnroll
CN=DomainControllerAuthenticationECC,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\AdministratorGenericWrite, WriteDacl, WriteOwner, DSSelf, Write all prop
CN=DomainControllerAuthenticationECC,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\Domain ControllersEnroll
CN=DomainControllerAuthenticationECC,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\Enterprise Read-only Domain ControllersEnroll
CN=EFS,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationDomain UsersEnroll
CN=Machine,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationDomain ComputersEnroll
CN=SmartcardLogon,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationAuthenticated UsersEnroll
CN=SmartcardLogonforKSP,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationAuthenticated UsersEnroll
CN=SmartcardLogonforKSP,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\AdministratorGenericWrite, WriteDacl, WriteOwner, DSSelf, Write all prop
CN=SubCA,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationAuthenticated UsersEnroll
CN=User,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationDomain UsersEnroll
CN=UserTest,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationDomain UsersEnroll
CN=UserTest,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\AdministratorGenericWrite, WriteDacl, WriteOwner, DSSelf, Write all prop
CN=Userwithapproval(seePending),CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationDomain UsersEnroll
CN=Userwithapproval(seePending),CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=ConfigurationTEST\AdministratorGenericWrite, WriteDacl, WriteOwner, DSSelf, Write all prop

Domain Controller Certificate

This section lists certificates in use on Domain Controllers. They give an attacker hints about the PKI configuration.

Number of DC certificates: 1

[1]
DC NameSubjectSAN ?EKU ?Template ?NotBeforeNotAfterModule sizeSignature Alg
WIN-PGAHI2ECI8EWIN-PGAHI2ECI8E.test.mysmartlogon.comClient Authentication, Server Authentication, Smart Card Logon, Domain Controller Authentication(1.3.6.1.4.1.311.21.8.12474800.5928062.9848222.15073602.853688.227.1.28)2015-03-08 12:52:18Z2025-03-08 12:52:18Z2048sha1RSA

Azure AD Connect settings

Azure AD Connect help maintaining a synchronization between the Active Directory and Azure AD. Azure AD Connect servers should be considered as Tiers0 as they usually have the right to read the hashes of the user passwords.

Identifier ?Computer ?Tenant ?IsEnabled ?Created ?LastLogon ?PwdLastSet ?Computer object found ?

WSUS settings

WSUS settings allow workstations and servers located on the intranet to be updated. The reference documentation is here. Here are the settings found in GPO.

Policy NameWSUS Server ?UseWUServer ?ElevateNonAdmins ?AUOptions ?NoAutoUpdate ?NoAutoRebootWithLoggedOnUsers ?

Exchange settings

Echange is the mail server of Microsoft. Because it is deeply integrated into the Active Directory, it is a component to be monitored

PingCastle is checking objects of type msExchExchangeServer and the schema to provide the information below.

NameIn service dateVersionProxy

SCCM settings

SCCM or its more recent name Microsoft Endpoint Manager is the Microsoft tool to manage the workstations and servers. It is used typically to deploy packages.

PingCastle is checking objects of type mSSMSManagementPoint and the schema to provide the information below.

NameVersionClient operational versionAAD TenantIDAAD TenantName

Service Connection Points

Service Connection Points are a configuration stored in the AD to expose services to all computers.

Service ?Class ?DNS ?Binding Info ?DN ?

Replacement of RC4 by AES in kerberos

This section checks for known pain points in AES activation and RC4 removal for kerberos

This section is here to evaluate the know problems when removing RC4. If you plan to do so, you should check all the items highlighted below and proceed with a small group of test computers.

Please see the following articles:

This program will proceed to know:

  • That the infrastructure is compatible with AES. It will asserts that all client accounts have an AES hash.
  • That all services (trust, ...) can accept AES kerberos tickets. This is done by checking the special attribute msDS-SupportedEncryptionTypes.
  • That the AES algorithm is pushed to the client by GPO. This is done by looking at the setting 'Configure encryption types allowed for Kerberos'.

Infrastructure

This program starts by determining for how long the infrastructure in place is compatible with AES.

This is done by retrieving the creation date of the groupe 'Read-Only Domain Controllers' which is linked to the first DC compatible with AES (Windows Server 2008).

Installation date of the first DC compatible with AES: 2012-03-03 18:17:16Z

All passwords saved after this date have their hash saved with both RC4 and AES.

Krbtgt

To issue Kerberos ticket, the krbtgt account holding the kerberos secret key must have a password changed AFTER the installation of the first DC compatible with AES.

Last krbtgt change: 2019-03-10 18:21:24Z

OK

Domain Controllers

To support AES, all DC must be at least Windows 2008.

Domain ControllerOSAES compatible
WIN-PGAHI2ECI8EWindows 2008Yes
ADIANT-A7B9AAC6Windows XPYes

OK

Trusts

To be used over trusts, AES requires the trust to support this algorithm. This is done thought the special attribute msDS-SupportedEncryptionTypes.

Be aware that checking 'The other domain supports Kerberos AES Encryption' in the trust property disables RC4. This check is not recommended during the migration phase.

Trust PartnerCreation ?Is Active ? ?Algorithm ?AES compatible
mil ?2014-06-09 12:49:20ZFALSEDefault (RC4)No
test4.mysmartlogon.com ?2019-04-06 21:53:36ZFALSEDefault (RC4)No

Not OK

Azure

To be used over Azure, the special AzureSSO account must be setup to support AES.

No AzureAD SSO detected

OK

Service accounts

Kerberos tickets for services are signed by the password hash of the service account. The service account must be declared as compatible to handle AES. This is done through the special attribute named msDS-SupportedEncryptionTypes or by checking 'This account supports Kerberos AES XXX bit encryption' in the account properties.

The service account must also have a password newer than the first DC compatible with AES. If there was no password change, the creation date must be newer than the first DC compatible with AES.

If a service account is not compatible, you will received error messages like 'The encryption type requested is not supported by the KDC'. See the following KB for SharePoint of SCCM errors:

Number of service account found without AES configuration: 2

[2]
NameCreationLast logonDistinguished name
ADIANT-2CC70D66$2013-04-01 09:32:22Z2013-04-01 11:32:26ZCN=ADIANT-2CC70D66,CN=Computers,DC=test,DC=mysmartlogon,DC=com
ADIANT-A7B9AAC6$2013-04-01 10:10:33Z2018-11-09 07:29:04ZCN=ADIANT-A7B9AAC6,CN=Computers,DC=test,DC=mysmartlogon,DC=com

Not OK

GPO to set encryption

The algorithm to use for kerberos request is decided by a local GPO which is overwritten by domain GPO.

Here is the list of domain GPO altering the kerberos algorithms

Policy NameAlgorithm ?AES compatibleRC4 compatible
Default Domain Controllers Policy ?DES-CBC-CRC, DES-CBC-MD5, RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96YesYes

OK

This section focuses on security checks specific to the Active Directory environment.

Backup

The program checks the last date of the AD backup. This date is computed using the replication metadata of the attribute dsaSignature (reference).

Last backup date: Never

LAPS

LAPS is used to have a unique local administrator password on all workstations / servers of the domain. Then this password is changed at a fixed interval. The risk is when a local administrator hash is retrieved and used on other workstation in a pass-the-hash attack. Please note that the LAPS schema is installed on the forest and as a consequence the installation date can be before the domain creation date.

Mitigation: having a process when a new workstation is created or install LAPS and apply it through a GPO

LAPS installation date: 2019-03-22 21:12:37Z

Here is the list of computers joined to the domain by users who have access to the LAPS password (or can modify the security to see it). This program looks if the mS-DS-CreatorSID is found: on the owner or on security permissions such as write owner, write security descriptor and all extended rights.

[1]
NameCreationLast logonDistinguished name
CREATOR$2021-05-13 07:03:09ZNeverCN=Creator$,CN=Computers,DC=test,DC=mysmartlogon,DC=com

Windows Event Forwarding (WEF)

Windows Event Forwarding is a native mechanism used to collect logs on all workstations / servers of the domain. Microsoft recommends to Use Windows Event Forwarding to help with intrusion detection Here is the list of servers configured for WEF found in GPO

Number of WEF configuration found: 3

[3]
GPO NameOrderServer
WEF test1Server=http://192.168.0.25:5985/wsman/SubscriptionManager/WEC
WEF test2test
WEF test3teset2

krbtgt (Used for Golden ticket attacks)

The account password for the krbtgt account should be rotated twice yearly at a minimum. More frequent password rotations are recommended, with 40 days the current recommendation by ANSSI. Additional rotations based on external events, such as departure of an employee who had privileged network access, are also strongly recommended.

You can perform this action using this script

You can use the version gathered using replication metadata from two reports to guess the frequency of the password change or if the two consecutive resets have been done. Version starts at 1.

Kerberos password last changed: 2019-03-10 18:21:24Z version: 3

AdminSDHolder (detect temporary elevated accounts)

This control detects accounts which are former 'unofficial' admins. Indeed when an account belongs to a privileged group, the attribute admincount is set. If the attribute is set without being an official member, this is suspicious. To suppress this warning, the attribute admincount of these accounts should be removed after review.

Number of accounts to review: 1

[1]
NameCreationLast logonEvent dateDistinguished name
wrongaccount92016-03-30 13:02:35ZNever2018-11-07 22:05:49ZCN=wrongaccount9,OU=TestOU,DC=test,DC=mysmartlogon,DC=com

Unix Passwords

This control detects if one of the attributes userPassword or unixUserPassword has been set on accounts. Indeed, these attributes are designed to store encrypted secrets for unix (or mainframe) interconnection. However in the large majority, interconnected systems are poorly designed and the user password is stored in these attributes in clear text or poorly encrypted. The userPassword attribute is also used in classic LDAP systems to change the user password by setting its value. But, with Active Directory, it is considered by default as a normal attribute and doesn't trigger a password but shows instead the password in clear text.

Number of accounts to review: 1

[1]
NameCreationLast logonEvent dateDistinguished name
wrongaccount82016-03-28 10:40:52ZNever2020-07-26 11:27:08ZCN=wrongaccount8,CN=Users,DC=test,DC=mysmartlogon,DC=com

Java code reference

This control detects if one of the attributes javaCodebase, javaFactory or javaClassname has been set on accounts. Indeed, these attributes are designed to add custom code to AD object when running java code. However it can be abused to run code on servers having the flag com.sun.jndi.ldap.object.trustURLCodebase set to true. This is a vulnerability similar to the log4shell vulnerability.

Java Schema extension: Not Found

No active user account found with Java code

NULL SESSION (anonymous access)

This control detects domain controllers which can be accessed without authentication. Hackers can then perform a reconnaissance of the environement with only a network connectivity and no account at all.

Domain controllers vulnerable: 1

[1]
Domain Controller
WIN-PGAHI2ECI8E

Smart Card and Password

This control detects users which use only smart card and whose password hash has not been changed for at least 90 days. Indeed, once the smart card required check is activated in the user account properties, a random password hash is set. But this hash is not changed anymore like for users having a password whose change is controlled by password policies. As a consequence, a capture of the hash using a memory attack tool can lead to a compromise of this account unlimited in time. The best practice is to reset these passwords on a regular basis or to uncheck and check again the "require smart card" property to force a hash change.

Users with smart card and having their password unchanged since at least 90 days: 3

[3]
NameCreationLast logonDistinguished name
BlueHat2018-01-19 15:23:37ZNeverCN=BlueHat,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongaccount102018-08-20 14:22:43ZNeverCN=wrongaccount10,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
wrongAccount52015-06-26 15:47:18ZNeverCN=wrongAccount5,OU=TestOU,DC=test,DC=mysmartlogon,DC=com

Logon scripts

You can check here for backdoors or typos in the scriptPath attribute

Script NameCount
None21

Advanced

This section display advanced information, if any has been found

Hardened Paths configuration

Policy NameKeyRequireIntegrityRequireMutualAuthenticationRequirePrivacy
Default Domain Controllers Policy ?\\*\SYSVOLDisabledDisabledDisabled

Password policies

Note: PSO (Password Settings Objects) will be visible only if the user, which collected the information, has the permission to view it.
PSO shown in the report will be prefixed by "PSO:"

Policy NameComplexityMax Password AgeMin Password AgeMin Password LengthPassword HistoryReversible EncryptionLockout ThresholdLockout DurationReset account counter locker after
Test GPO site ?Not SetNot SetNot Set0Not SetNot SetNot SetNot SetNot Set
Default Domain Policy ?FalseNever expires0 day00False0Not SetNot Set
test kerberos armoring ?Not SetNot SetNot SetNot Set1Not SetNot SetNot SetNot Set
Default Domain Controllers Policy ?FalseNever expires0 day0Not SetNot SetNot SetNot SetNot Set
test nfc 2 [Not linked] ?FalseNever expires0 day1Not SetNot SetNot SetNot SetNot Set
PSO:testFalse90 day(s)0 day05False505 minute(s)1 minute(s)
PSO:test2FalseNever expires0 day00True1030 minute(s)30 minute(s)

Screensaver policies

This is the settings related to screensavers stored in Group Policies. Each non compliant setting is written in red.

Policy NameScreensaver enforcedPassword requestStart after (seconds)Grace Period (seconds)
test nfc 2 [Not linked] ?TrueTrue90000Not Set
GPO

This section focuses on security settings stored in the Active Directory technical security policies.

Obfuscated Passwords

The password in GPO are obfuscated, not encrypted. Consider any passwords listed here as compromised and change them immediately.

GPO NamePassword originUserNamePasswordChangedOther
WEF test [Not linked] ?registry.xmlssssdddd2019-09-17 16:56:10ZAutologon info
test nfc 2 [Not linked] ?groups.xmladministratorvletoux2016-04-02 19:40:14ZNewName:adiant-admin
test nfc 2 [Not linked] ?drives.xmladiantvletoux2016-04-02 19:39:33ZPath:test
test nfc 2 [Not linked] ?groups.xmltesttest2016-04-02 20:21:02Z

Restricted Groups

Giving local group membership in a GPO is a way to become administrator.
The local admin of a domain controller can become domain administrator instantly.

Security settings

A GPO can be used to deploy security settings to workstations.
The best practice out of the default security baseline is reported in green.
The following settings in red are unsual and may need to be reviewed.
Each setting is accompanied with its value and a link to the GPO explanation.

You will find below the checks where no occurences have been found

Policy NameSettingValue
Default Domain Policy ?Recovery console: Allow automatic administrative logonEnabled
Default Domain Policy ?LDAP client signing requirements (Technical details)None (Do not request signature)
Default Domain Policy ?Do not store LAN Manager hash value on next password change (Technical details)Disabled
Default Domain Policy ?Turn off multicast name resolution (Technical details)LLMNR Enabled
test kerberos armoring ?KDC support for claims compound authentication and Kerberos armoringEnabled
Default Domain Controllers Policy ?Allow anonymous SID/Name translation (Technical details)Enabled
Default Domain Controllers Policy ?Microsoft network server: Digitally sign communications (if client agrees) (Technical details)Disabled
Default Domain Controllers Policy ?Network security: Configure encryption types allowed for KerberosDES-CBC-CRC, DES-CBC-MD5, RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96

Here are the security checks that have been checked by PingCastle and where no applicable GPO has been found.

Audit settings

Audit settings allow the system to generate logs which are useful to detect intrusions. Here are the settings found in GPO.

Simple audit events are described here and Advanced audit events are described here

You can get a list of all audit settings with the command line: auditpol.exe /get /category:* (source)

Simple audit settings are located in: Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / Audit Policy. Simple audit settings are named [Simple Audit].

Advanced audit settings are located in: Computer Configuration / Policies / Windows Settings / Security Settings / Advanced Audit Policy Configuration. This category is displayed below.

Policy NameCategorySettingValue
Default Domain Policy ?Logon/LogoffLogonSuccess and Failure
Default Domain Controllers Policy ?Account LogonKerberos Authentication ServiceSuccess and Failure
Default Domain Controllers Policy ?Account LogonKerberos Service Ticket OperationsSuccess and Failure
Default Domain Controllers Policy ?Account LogonOther Account Logon EventsSuccess and Failure
Default Domain Controllers Policy ?Account ManagementComputer Account ManagementSuccess and Failure
Default Domain Controllers Policy ?Account ManagementSecurity Group ManagementSuccess and Failure
Default Domain Controllers Policy ?Account ManagementUser Account ManagementSuccess and Failure
Default Domain Controllers Policy ?Detailed TrackingDPAPI ActivitySuccess and Failure
Default Domain Controllers Policy ?Detailed TrackingProcess CreationSuccess and Failure
Default Domain Controllers Policy ?Logon/LogoffLogoffSuccess and Failure
Default Domain Controllers Policy ?Logon/LogoffLogonSuccess and Failure
Default Domain Controllers Policy ?Logon/LogoffSpecial LogonSuccess and Failure
Default Domain Controllers Policy ?Object AccessOther Object AccessSuccess and Failure
Default Domain Controllers Policy ?Policy ChangeAudit Policy ChangeSuccess
Default Domain Controllers Policy ?Policy ChangeAuthentication Policy ChangeSuccess and Failure
Default Domain Controllers Policy ?Privilege UseSensitive Privilege UseSuccess and Failure
Default Domain Controllers Policy ?SystemSecurity System ExtensionSuccess and Failure

Privileges

Giving privileges in a GPO is a way to become administrator without being part of a group.
For example, SeTcbPriviledge gives the right to act as SYSTEM, which has more privileges than the administrator account.

GPO NamePrivilegeMembers
Default Domain Policy ?SeDebugPrivilegeEveryone
Default Domain Policy ?SeLoadDriverPrivilegeEveryone
Default Domain Controllers Policy ?SeAssignPrimaryTokenPrivilegeIIS APPPOOL\WSEnrollmentServer
Default Domain Controllers Policy ?SeAssignPrimaryTokenPrivilegeIIS APPPOOL\Classic .NET AppPool
Default Domain Controllers Policy ?SeAssignPrimaryTokenPrivilegeIIS APPPOOL\DefaultAppPool
Default Domain Controllers Policy ?SeAssignPrimaryTokenPrivilegeNT AUTHORITY\NETWORK SERVICE
Default Domain Controllers Policy ?SeAssignPrimaryTokenPrivilegeNT AUTHORITY\LOCAL SERVICE
Default Domain Controllers Policy ?SeAssignPrimaryTokenPrivilegeIIS APPPOOL\SmartPolicy
Default Domain Controllers Policy ?SeAssignPrimaryTokenPrivilegeIIS APPPOOL\crl.eid.belgium.be
Default Domain Controllers Policy ?SeBackupPrivilegeBUILTIN\Server Operators
Default Domain Controllers Policy ?SeBackupPrivilegeBUILTIN\Backup Operators
Default Domain Controllers Policy ?SeBackupPrivilegeAdministrators
Default Domain Controllers Policy ?SeDebugPrivilegeAdministrators
Default Domain Controllers Policy ?SeLoadDriverPrivilegeBUILTIN\Print Operators
Default Domain Controllers Policy ?SeLoadDriverPrivilegeAdministrators
Default Domain Controllers Policy ?SeMachineAccountPrivilegeAuthenticated Users
Default Domain Controllers Policy ?SeMachineAccountPrivilegeAuthenticated Users
Default Domain Controllers Policy ?SeRestorePrivilegeBUILTIN\Server Operators
Default Domain Controllers Policy ?SeRestorePrivilegeBUILTIN\Backup Operators
Default Domain Controllers Policy ?SeRestorePrivilegeAdministrators
Default Domain Controllers Policy ?SeSecurityPrivilegeAdministrators
Default Domain Controllers Policy ?SeTakeOwnershipPrivilegeAdministrators
Default Domain Controllers Policy ?SeEnableDelegationPrivilegeAdministrators
test nfc 2 [Not linked] ?SeDebugPrivilegeadiant-test
test nfc 2 [Not linked] ?SeDebugPrivilegeEveryone
test nfc 2 [Not linked] ?SeLoadDriverPrivilegeEveryone

Login

Login authorization and restriction can be set by GPOs. Indeed, by default, everyone is allowed to login on every computer except domain controllers. Defining login restriction is a way to have different isolated tiers. Here are the settings found in GPOs.

GPO NamePrivilegeMembers
Banned Login for admin ?Deny access to this computer from the network ?Domain Administrators
Banned Login for admin ?Deny log on as a batch job ?Domain Administrators
Banned Login for admin ?Deny log on as a service ?Domain Administrators
Banned Login for admin ?Deny log on locally ?Domain Administrators
Banned Login for admin ?Deny logon through Remote Desktop Services ?Domain Administrators
Banned Login for admin ?Allow log on locally ?Domain Users
Banned Login for admin ?Allow log on locally ?Administrators
Banned Login for admin ?Allow logon through Remote Desktop Services ?Domain Users
Default Domain Controllers Policy ?Log on as a batch job ?TEST\test
Default Domain Controllers Policy ?Log on as a batch job ?BUILTIN\Performance Log Users
Default Domain Controllers Policy ?Log on as a batch job ?BUILTIN\IIS_IUSRS
Default Domain Controllers Policy ?Log on as a batch job ?BUILTIN\Backup Operators
Default Domain Controllers Policy ?Log on as a batch job ?Administrators
Default Domain Controllers Policy ?Allow log on locally ?BUILTIN\Account Operators
Default Domain Controllers Policy ?Allow log on locally ?Administrators
Default Domain Controllers Policy ?Allow log on locally ?Authenticated Users
Default Domain Controllers Policy ?Allow log on locally ?BUILTIN\Backup Operators
Default Domain Controllers Policy ?Allow log on locally ?Everyone
Default Domain Controllers Policy ?Allow log on locally ?BUILTIN\Print Operators
Default Domain Controllers Policy ?Allow log on locally ?BUILTIN\Server Operators
Default Domain Controllers Policy ?Access this computer from the network ?BUILTIN\Pre-Windows 2000 Compatible Access
Default Domain Controllers Policy ?Access this computer from the network ?NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
Default Domain Controllers Policy ?Access this computer from the network ?Authenticated Users
Default Domain Controllers Policy ?Access this computer from the network ?Administrators
Default Domain Controllers Policy ?Access this computer from the network ?Everyone
Default Domain Controllers Policy ?Allow logon through Remote Desktop Services ?Authenticated Users

GPO Login script

A GPO login script is a way to force the execution of data on behalf of users. Only enabled users are analyzed.

GPO NameActionSourceCommand lineParameters
Default Domain Controllers Policy ?LogonRegistry.pol (Computer section)\\test.mysmartlogon.com\sysvol\test.mysmartlogon.com\bin\test.ps1
test nfc 2 [Not linked] ?Logonscripts.ini (User section)test.vbsmachin trust
test nfc 2 [Not linked] ?Logoffscripts.ini (User section)test123
test nfc 2 [Not linked] ?Logoffscripts.ini (User section)tatayoyo
test nfc 2 [Not linked] ?Logonpsscripts.ini (User section)test.ps1tsettte
test nfc 2 [Not linked] ?Logoffpsscripts.ini (User section)test456

GPO Deployed Files

A GPO can be used to deploy applications or copy files. These files may be controlled by a third party to control the execution of local programs.

GPO NameTypeFile
WEF test [Not linked] ?Files (User section)\\test.mysmartlogon.com\sysvol\test.mysmartlogon.com\bin\test.txt
WEF test [Not linked] ?Application (Computer section)\\test.mysmartlogon.com\SYSVOL\test.mysmartlogon.com\bin\7z1900.msi
WEF test [Not linked] ?Application (Computer section)\\test.mysmartlogon.com\SYSVOL\test.mysmartlogon.com\bin\7z1900.msi