test.mysmartlogon.com - Healthcheck analysis

Date: 2021-07-28 - Engine version: 2.10.0.0

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

12 rules matched

050100

Trusts : 100 /100

It is about links between two Active Directories

4 rules matched

050100

Privileged Accounts : 100 /100

It is about administrators of the Active Directory

19 rules matched

050100

Anomalies : 100 /100

It is about specific security control points

27 rules matched

Stale Objects Privileged accounts Trusts Anomalies
Inactive user or computer
Account take over
Old trust protocol
Audit
Network topography
ACL Check
SID Filtering
Backup
Object configuration
Admin control
SIDHistory
Certificate take over
Obsolete OS
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

16 rule(s) matched

Level 2

17 rule(s) matched

Level 3

25 rule(s) matched

Level 4

3 rule(s) matched

Level 5

1 rule(s) matched

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

+ 60 Point(s)

Find Password GPO

Rule ID:

A-PwdGPO

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

20 points per discovery

Documentation:

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

Details:

The detail can be found in the Obfuscated Passwords

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

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

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

Advised solution:

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

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

Points:

100 points if the occurence is greater 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
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection
[FR]ANSSI - Outbound forest trust relationships with sID History enabled (vuln1_trusts_forest_sidhistory)1
[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 - Recommandations de sécurité relatives à Active Directory - R16 [paragraph.3.3.1.6]
[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 unsecure backup media or perform a local privilege escalation to become the DC admin and thus the AD admin.
Local logon requires usually physical interaction, which explains why network seggregation is a best practice, but this can be bypassed. Indeed VNC or remote server management software is a way to perform local logon remotely.
In addition, remote server management software have been the subject of many vulnerabilites, some of them can be exploited even if this software is disabled.

Advised solution:

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

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

GPO Account Privilege
Default Domain Controllers Policy Everyone SeInteractiveLogonRight
Default Domain Controllers Policy Authenticated Users SeInteractiveLogonRight
Default Domain Controllers Policy Authenticated Users SeRemoteInteractiveLogonRight
+ 25 Point(s)

Check if all DC have no constrained delegation.

Rule ID:

P-DelegationDCa2d2

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

25 points per discovery

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controller Delegate Identifier
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 anonymous, everyone, authenticated users, domain users, domain computers and builtin-users groups.

Advised solution:

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

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)

Domain Controller Update

Rule ID:

S-DC-NotUpdated

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

15 points if present

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controller Reason
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 depends 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

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

Check if Service Accounts are domain administrators

Rule ID:

P-ServiceDomainAdmin

Description:

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

Technical explanation:

"Service Accounts" can imply a high security risk as their password are stored in clear text in the LSA database, which can then be easily exploited using Mimikatz or Cain&Abel for instance. In addition, their passwords don't change and can be used in kerberoast attacks.

Advised solution:

To mitigate the security risk, it is strongly advised to lower the privileges of the "Service Accounts", meaning that they should be removed from the "Domain Administrator" group, while ensuring that the password of each and every "Service Account" is higher than 20 characters

Points:

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

Documentation:

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

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

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

Advised solution:

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

Points:

5 points per discovery

Documentation:

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

Details:

The detail can be found in Admin Groups

Group User
Administrators Adiant
Domain Administrators Adiant
Schema Administrators Adiant
+ 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

Account Creation LastChanged
wrongaccount8 2016-03-28 10:40:52Z 2016-03-28 12:40:52Z
teste ( 2017-01-09 18:07:43Z Never
wrongAccount5 2015-06-26 15:47:18Z Never
wrongAccount1 2015-06-26 10:20:33Z Never
+ 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
[MITRE]T1207 Rogue Domain Controller
[FR]ANSSI - Domain controllers in inconsistent state (vuln1_dc_inconsistent_uac)1

Details:

The detail can be found in Domain controllers

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

Check if all admin accounts do support kerberos pre-authentication

Rule ID:

S-NoPreAuthAdmin

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

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

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

Check if the Dns Admins group is not empty

Rule ID:

P-DNSAdmin

Description:

The purpose is to ensure that the Dns Admin 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:

You should remove the members of the DNS admin 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:

5 points if present

Documentation:

https://medium.com/@esnesenon/feature-not-bug-dnsadmin-to-dc-compromise-in-one-line-a0f779b8dc83
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/007efcd2-2955-46dd-a59e-f83ae88f4678
[FR]ANSSI - DnsAdmins group members (vuln1_dnsadmins)1
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

Details:

The detail can be found in Admin Groups

+ 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 weak if enabled by a GPO.

Technical explanation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

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

Details:

The detail can be found in Security settings

GPO Setting
Default Domain Policy NoLMHash
+ 5 Point(s)

Obsolete Domain Controller (Windows 2008)

Rule ID:

S-DC-2008

Description:

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

Technical explanation:

The OS Windows 2008 is not supported anymore by Microsoft (except when migrated to Azure) and any vulnerability found will not be patched unless an expensive support contrat has been purchased.

Advised solution:

To resolve this security risk, the only way is to decommission DC running Windows 2008 OS, in order to use new versions that are more secured 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 powerfull privileges.
While an active Domain Controller change its password every 30 days, an inactive account can be involved in a domain compromise.
Indeed, another account, which have 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 - Recommandations de sécurité relatives à Active Directory - R45 [paragraph.3.6.6.2]
[FR]ANSSI - Inactive domain controllers (vuln1_password_change_inactive_dc)1

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

GPO Account Privilege
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 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:
GPO Item Account Right
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)

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

Rule ID:

A-Krbtgt

Description:

The purpose is to alert when the password for the krbtgt account can be used to compromise the whole domain. This password can be used to sign every kerberos ticket. Monitoring it closely often mitigates the risk of golden ticket attacks greatly.

Technical explanation:

Kerberos is an authentication protocol. It is using to sign its tickets a secret stored as the password of the krbtgt account. If the hash of the password of the krbtgt account is retrieved, it can be use to generate authentication tickets at will.
To mitigate this attack, it is recommended to change the krbtgt password between 40 days and 6 months. If it not the case, every backup done until the last password change of the krbtgt account can be used to emit Golden tickets, compromising the entire domain.
Retrieval of this secret is one of the highest priority in an attack, as this password is rarely changed and offer a long term backdoor.
Also this attack can be performed using the former password of the krbtgt account. That's why the krbtgt password should be changed twice to invalidate its leak.

Advised solution:

The password of the krbtgt account should be changed twice to invalidate the golden ticket attack.
Beware: two changes of the krbtgt password not replicated to domain controllers can break these domain controllers You should wait at least 8 hours between each krbtgt password change.

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

Points:

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

Documentation:

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

Details:

The detail can be found in Krbtgt

+ 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]
[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

Details:

The detail can be found in GPO Login script

Script Account Right
test.ps1 Authenticated Users Modify, Synchronize
\\test.mysmartlogon.com\sysvol\test.mysmartlogon.com\bin\test.ps1 Authenticated Users Modify, Synchronize
+ 30 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" and to "Authenticated Users"

Technical explanation:

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

Advised solution:

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

Points:

15 points per discovery

Documentation:

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

Details:

The detail can be found in Delegations

DN delegation right
DC=test,DC=mysmartlogon,DC=com Everyone GenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
OU=TestOU,DC=test,DC=mysmartlogon,DC=com Everyone READ_PROP_ms-mcs-admpwd
+ 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 being changed and that there was either a problem with the remote domain or that the remote domain does not exist anymore.

Advised solution:

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

Points:

20 points if present

Documentation:

https://msdn.microsoft.com/fr-fr/library/ms680921(v=vs.85).aspx
[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)

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

Rule ID:

P-RecoveryModeUnprotected

Description:

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

Technical explanation:

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

Advised solution:

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

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

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 other users and impersonate them using it.

Advised solution:

Review the permissions that allow a wide enrollement 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/
[MITRE]T1558 Steal or Forge Kerberos Tickets

Details:

The detail can be found in Certificate Templates

Name
SubCA
+ 15 Point(s)

Check the if a custom subject can be pushed on an authentication certificate templates

Rule ID:

A-CertTempCustomSubject

Description:

The purpose of this rule is to ensure that there is no certificate request having an authentication purpose whose subject can be modified

Technical explanation:

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

Advised solution:

On the certificate template properties, uncheck in the property sheet "Subject Name" the field "Supply in the request".
Or in alternative, restrict this template to a restricted 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/
[MITRE]T1558 Steal or Forge Kerberos Tickets

Details:

The detail can be found in Certificate Templates

Name
SmartcardLogonforKSP
SubCA
+ 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

Advised solution:

Review the security permissions of this certificate template and remove the write access to everyone-like group such as domain user, 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

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 certificate on behalf 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 enrollement 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/
[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 if all computers have changed their passwords in the last 3 months.

Rule ID:

S-PwdLastSet-90

Description:

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

Technical explanation:

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

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

Advised solution:


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

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

Points:

15 points if present

Documentation:

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

Details:

The detail can be found in Computer information

Computer Creation LastUsed LastChange
WIN-1MLHM2RAF4U$ 3/3/2012 6:24:33 PM 5/21/2020 3:17:08 PM 2/15/2019 7:19:05 PM
WIN-3RC77Q4T0SP$ 3/22/2019 9:30:21 PM 12/1/2019 1:01:52 PM 5/8/2019 12:28:21 PM
DESKTOP-RLP9BES$ 3/23/2019 6:38:12 AM 6/16/2020 5:46:39 PM 3/23/2019 7:38:12 AM
+ 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 represents a high risk because they can fairly easily be brute-forced. Most CERT and agencies advises for at least 8 characters (and often this number goes up to 12)

Advised solution:

To solve the issue, the best way is to either remove the GPO enabling short password, or to modify it in order to increase the password length to at least 8 characters

Points:

10 points if present

Documentation:

https://www.microsoft.com/en-us/research/publication/password-guidance/
[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
Default Domain Policy
Test GPO site
Default Domain Controllers Policy
+ 10 Point(s)

Retrieve data from the domain without any account

Rule ID:

A-NullSession

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

10 points if present

Documentation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

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

+ 5 Point(s)

Obsolete OS (Windows 2008)

Rule ID:

S-OS-2008

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

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

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

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]
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[FR]ANSSI - Accounts or groups with SID history set (vuln3_sidhistory_present)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 Card to protected sensitive account is a good thing. Nevertheless, when the "Smart Card required" flag is set, the password of the account is not changed anymore by default. Internally the hash of this password is used to sign the user's kerberos tickets, making this account vulnerable to Silver ticket attacks. The rule is triggered 90 days after the last change of the attribute unicodePwd. This value is collected using the replication metadata of the attribute 589914

Advised solution:

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

Points:

30 points if present

Documentation:

https://blogs.technet.microsoft.com/positivesecurity/2017/05/17/smartcard-and-pass-the-hash/
[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.
[MITRE]T1110.002 Brute Force: Password Cracking
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R38 [paragraph.3.6.2.2]

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" (and are not member 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 has 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). Please note that there is a section bellow in this report named "Admin Groups" which give more information.

Points:

20 points if present

Documentation:

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

Details:

The detail can be found in Admin Groups

+ 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 an SIDHistory attribute using the command: get-ADObject -ldapfilter "(sidhistory=*)" -properties sidhistory.
Each security descriptor of the domain (including file shares for example) should be reviewed to be rewritten with the new SID of the account. Then, the attribute can be removed of these accounts using the migration tool or a PowerShell snippet Remove-SIDHistory once the migration is completed. Please note that once the SID History has been removed, it cannot be added back again without doing a real migration. Hopefully hacking tools such as mimikatz can be used to undo a deletion with for example the lsadump::dcshadow attack.

Points:

5 points per discovery with a minimal of 15 points

Documentation:

[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

SID Object(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 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 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

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

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

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

Advised solution:

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

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

DC Protocol
WIN-PGAHI2ECI8E Ssl2
WIN-PGAHI2ECI8E Ssl3
+ 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 controller Owner
CN=ADIANT-A7B9AAC6,CN=Computers,DC=test,DC=mysmartlogon,DC=com TEST\Administrator
+ 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 this issues before disabling SMB v1, as it will generates additional errors.

Points:

10 points if present

Documentation:

https://github.com/lgandx/Responder-Windows
https://blogs.technet.microsoft.com/josebda/2015/04/21/the-deprecation-of-smb1-you-should-be-planning-to-get-rid-of-this-old-smb-dialect
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-2016-ACT-039
[FR]ANSSI CERTFR-2017-ACT-019

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.

Advised solution:

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

Points:

10 points if present

Documentation:

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

Advised solution:

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

Points:

10 points if present

Documentation:

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

Details:

The detail can be found in Admin Groups

+ 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 collect the right set of events.

Technical explanation:

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

Advised solution:

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 GPO for a given domain controller.

Type Audit Problem Rationale Domain 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
+ 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:

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

Details:
Member
CN=BlueHat,CN=Users,DC=test,DC=mysmartlogon,DC=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 explicitly disabled.

Technical explanation:

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

Advised solution:

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

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 has 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 if a migration is in progress

Rule ID:

S-Domain$$$

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

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

+ 2 Point(s)

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

Rule ID:

A-PreWin2000Other

Description:

The purpose is check 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 Intermediate Certificates using unsafe hashing algorithm (SHA1)

Rule ID:

A-SHA1IntermediateCert

Description:

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

Technical explanation:

The SHA1 hashing algorithm is not considered as safe. There are design flaws inherent to the algorithm that allow an attacker to generate a hash collision in less than a brute-force time

Advised solution:

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

Points:

1 points if present

Documentation:

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

Details:

The detail can be found in Certificates

GPO Subject
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
+ 1 Point(s)

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

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

Details:

The detail can be found in Certificates

Source Subject Module Expires
GPO:Default Domain Policy;Machine CN=CA, DC=test, DC=mysmartlogon, DC=com 2048 2030-10-02 09:44:04Z
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=CA, DC=test, DC=mysmartlogon, DC=com 2048 2030-10-02 09:44:04Z
NTLMStore CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI 2048 2041-09-15 09:08:21Z
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 attribute unixUserPassword and userPassword should be cleared from the mentionned user account, unless the remote system is known to have a strong cryptographic protocol.

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Unix Passwords

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 Protected Users group.

Technical explanation:

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[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

Details:

The schema version is indicated in Domain Information

Informative rule

Check for Root Certificates using unsafe hashing algorithm (SHA1)

Rule ID:

A-SHA1RootCert

Description:

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

Technical explanation:

The SHA1 hashing algorithm is not considered as safe. There are design flaws inherent to the algorithm that allow an attacker to generate a hash collision in less than a brute-force time

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://tools.ietf.org/html/rfc6194
[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

GPO Subject
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 if there is powershell logging enabled.

Rule ID:

A-AuditPowershell

Description:

The purpose is to ensure that Powershell logging is enabled.

Technical explanation:

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

Advised solution:

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

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

Details:

The detail can be found in Security settings

Informative rule

Check that operators group are empty

Rule ID:

P-OperatorsEmpty

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

[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

Group Members
Account Operators 1

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 are linked to an account which exists

Technical explanation:

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

Advised solution:

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

Points:

15 points if present

Documentation:

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

Details:

The detail can be found in Delegations

DN delegation right
CN=Users,DC=test,DC=mysmartlogon,DC=com S-1-5-21-4005144719-3948538632-2546531719-1115 WRITE_PROP_MEMBER, VAL_WRITE_SELF_MEMBERSHIP, EXT_RIGHT_FORCE_CHANGE_PWD
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 recommandations:
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 behind Kerberoast attack (offline crack 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 Account.

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Password Policies

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 check 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 on the exploitation vulnerability on legacy protocols such as the printer spooler.
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
[MITRE]T1210 Exploitation of Remote Services

This section represents an evaluation of the techniques available in the Mitre Att&ck®

Techniques

Initial Access

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

Privilege Escalation

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

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

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]
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[FR]ANSSI - Accounts or groups with SID history set (vuln3_sidhistory_present)3

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

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

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

Advised solution:

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

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

Points:

100 points if the occurence is greater 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
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection
[FR]ANSSI - Outbound forest trust relationships with sID History enabled (vuln1_trusts_forest_sidhistory)1
[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 - Recommandations de sécurité relatives à Active Directory - R16 [paragraph.3.3.1.6]
[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 an SIDHistory attribute using the command: get-ADObject -ldapfilter "(sidhistory=*)" -properties sidhistory.
Each security descriptor of the domain (including file shares for example) should be reviewed to be rewritten with the new SID of the account. Then, the attribute can be removed of these accounts using the migration tool or a PowerShell snippet Remove-SIDHistory once the migration is completed. Please note that once the SID History has been removed, it cannot be added back again without doing a real migration. Hopefully hacking tools such as mimikatz can be used to undo a deletion with for example the lsadump::dcshadow attack.

Points:

5 points per discovery with a minimal of 15 points

Documentation:

[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

SID Object(s)
S-1-5-18 1

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
[MITRE]T1207 Rogue Domain Controller
[FR]ANSSI - Domain controllers in inconsistent state (vuln1_dc_inconsistent_uac)1

Details:

The detail can be found in Domain controllers

Domain controller Problem
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 depends 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

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

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

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

Advised solution:

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

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

DC Protocol
WIN-PGAHI2ECI8E Ssl2
WIN-PGAHI2ECI8E Ssl3
+ 1 Point(s)

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

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

Details:

The detail can be found in Certificates

Source Subject Module Expires
GPO:Default Domain Policy;Machine CN=CA, DC=test, DC=mysmartlogon, DC=com 2048 2030-10-02 09:44:04Z
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=CA, DC=test, DC=mysmartlogon, DC=com 2048 2030-10-02 09:44:04Z
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 SHA1 hashing algorithm in Intermediate Certificate

Technical explanation:

The SHA1 hashing algorithm is not considered as safe. There are design flaws inherent to the algorithm that allow an attacker to generate a hash collision in less than a brute-force time

Advised solution:

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

Points:

1 points if present

Documentation:

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

Details:

The detail can be found in Certificates

GPO Subject
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 there is no use of the SHA1 hashing algorithm in Root Certificate

Technical explanation:

The SHA1 hashing algorithm is not considered as safe. There are design flaws inherent to the algorithm that allow an attacker to generate a hash collision in less than a brute-force time

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://tools.ietf.org/html/rfc6194
[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

GPO Subject
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 are domain administrators

Rule ID:

P-ServiceDomainAdmin

Description:

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

Technical explanation:

"Service Accounts" can imply a high security risk as their password are stored in clear text in the LSA database, which can then be easily exploited using Mimikatz or Cain&Abel for instance. In addition, their passwords don't change and can be used in kerberoast attacks.

Advised solution:

To mitigate the security risk, it is strongly advised to lower the privileges of the "Service Accounts", meaning that they should be removed from the "Domain Administrator" group, while ensuring that the password of each and every "Service Account" is higher than 20 characters

Points:

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

Documentation:

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

Details:

The detail can be found in Admin Groups

T1110.002 Brute Force: Password Cracking [2]

+ 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 Card to protected sensitive account is a good thing. Nevertheless, when the "Smart Card required" flag is set, the password of the account is not changed anymore by default. Internally the hash of this password is used to sign the user's kerberos tickets, making this account vulnerable to Silver ticket attacks. The rule is triggered 90 days after the last change of the attribute unicodePwd. This value is collected using the replication metadata of the attribute 589914

Advised solution:

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

Points:

30 points if present

Documentation:

https://blogs.technet.microsoft.com/positivesecurity/2017/05/17/smartcard-and-pass-the-hash/
[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.
[MITRE]T1110.002 Brute Force: Password Cracking
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R38 [paragraph.3.6.2.2]

Details:

The detail can be found in Smart Card and Password

+ 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 weak if enabled by a GPO.

Technical explanation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

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

Details:

The detail can be found in Security settings

GPO Setting
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 access without any account, aka NULL Sessions, within the Active Directory. A NULL Session is a session opened anonymously to access the AD, often used by attackers to perform a recon operation on the AD, to identify weaknesses

Technical explanation:

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

Advised solution:

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

Points:

10 points if present

Documentation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

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

+ 2 Point(s)

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

Rule ID:

A-PreWin2000Other

Description:

The purpose is check 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 [3]

+ 30 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" and to "Authenticated Users"

Technical explanation:

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

Advised solution:

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

Points:

15 points per discovery

Documentation:

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

Details:

The detail can be found in Delegations

DN delegation right
DC=test,DC=mysmartlogon,DC=com Everyone GenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
OU=TestOU,DC=test,DC=mysmartlogon,DC=com Everyone READ_PROP_ms-mcs-admpwd
+ 25 Point(s)

Check if all DC have no constrained delegation.

Rule ID:

P-DelegationDCa2d2

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

25 points per discovery

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controller Delegate Identifier
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 are linked to an account which exists

Technical explanation:

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

Advised solution:

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

Points:

15 points if present

Documentation:

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

Details:

The detail can be found in Delegations

DN delegation right
CN=Users,DC=test,DC=mysmartlogon,DC=com S-1-5-21-4005144719-3948538632-2546531719-1115 WRITE_PROP_MEMBER, VAL_WRITE_SELF_MEMBERSHIP, EXT_RIGHT_FORCE_CHANGE_PWD

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 attribute unixUserPassword and userPassword should be cleared from the mentionned user account, unless the remote system is known to have a strong cryptographic protocol.

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Unix Passwords

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

+ 60 Point(s)

Find Password GPO

Rule ID:

A-PwdGPO

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

20 points per discovery

Documentation:

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

Details:

The detail can be found in the Obfuscated Passwords

GPO login password
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 has 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 [2]

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

Advised solution:

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

Points:

20 points if present

Documentation:

https://msdn.microsoft.com/fr-fr/library/ms680921(v=vs.85).aspx
[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
+ 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 explicitly disabled.

Technical explanation:

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

Advised solution:

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

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

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

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

Points:

10 points if present

Documentation:

https://github.com/lgandx/Responder-Windows
https://blogs.technet.microsoft.com/josebda/2015/04/21/the-deprecation-of-smb1-you-should-be-planning-to-get-rid-of-this-old-smb-dialect
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-2016-ACT-039
[FR]ANSSI CERTFR-2017-ACT-019

Details:

The detail can be found in Domain controllers

Domain controller
WIN-PGAHI2ECI8E

T1558 Steal or Forge Kerberos Tickets [4]

+ 15 Point(s)

Check the if a custom subject can be pushed on an authentication certificate templates

Rule ID:

A-CertTempCustomSubject

Description:

The purpose of this rule is to ensure that there is no certificate request having an authentication purpose whose subject can be modified

Technical explanation:

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

Advised solution:

On the certificate template properties, uncheck in the property sheet "Subject Name" the field "Supply in the request".
Or in alternative, restrict this template to a restricted 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/
[MITRE]T1558 Steal or Forge Kerberos Tickets

Details:

The detail can be found in Certificate Templates

Name
SmartcardLogonforKSP
SubCA
+ 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 anyone

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 other users and impersonate them using it.

Advised solution:

Review the permissions that allow a wide enrollement 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/
[MITRE]T1558 Steal or Forge Kerberos Tickets

Details:

The detail can be found in Certificate Templates

Name
SubCA
+ 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 certificate on behalf 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 enrollement 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/
[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 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

Advised solution:

Review the security permissions of this certificate template and remove the write access to everyone-like group such as domain user, 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

Details:

The detail can be found in Certificate Templates

Name
CopyofCopyofEnrollmentAgent2
CopyofCopyofCopyofCopyofEnrollmentAgen4

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

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

Advised solution:

The password of the krbtgt account should be changed twice to invalidate the golden ticket attack.
Beware: two changes of the krbtgt password not replicated to domain controllers can break these domain controllers You should wait at least 8 hours between each krbtgt password change.

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

Points:

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

Documentation:

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

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

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

Advised solution:

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

Points:

5 points per discovery

Documentation:

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

Details:

The detail can be found in Admin Groups

Group User
Administrators Adiant
Domain Administrators Adiant
Schema Administrators Adiant

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

+ 5 Point(s)

Check if all admin accounts do support kerberos pre-authentication

Rule ID:

S-NoPreAuthAdmin

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

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

Account Created LastLogon
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 anonymous, everyone, authenticated users, domain users, domain computers and builtin-users groups.

Advised solution:

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

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

Advised solution:

To solve the issue, the best way is to either remove the GPO enabling short password, or to modify it in order to increase the password length to at least 8 characters

Points:

10 points if present

Documentation:

https://www.microsoft.com/en-us/research/publication/password-guidance/
[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
Default Domain Policy
Test GPO site
Default Domain Controllers Policy
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 behind Kerberoast attack (offline crack 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 Account.

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://www.microsoft.com/en-us/research/publication/password-guidance/
[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 check 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 on the exploitation vulnerability on legacy protocols such as the printer spooler.
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
[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 collect the right set of events.

Technical explanation:

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

Advised solution:

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 GPO for a given domain controller.

Type Audit Problem Rationale Domain 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 there is powershell logging enabled.

Rule ID:

A-AuditPowershell

Description:

The purpose is to ensure that Powershell logging is enabled.

Technical explanation:

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

Advised solution:

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

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

Details:

The detail can be found in Security settings

Active Directory Configuration

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

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

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

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]
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[FR]ANSSI - Accounts or groups with SID history set (vuln3_sidhistory_present)3

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

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

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

Advised solution:

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

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

Points:

100 points if the occurence is greater 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
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection
[FR]ANSSI - Outbound forest trust relationships with sID History enabled (vuln1_trusts_forest_sidhistory)1
[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 - Recommandations de sécurité relatives à Active Directory - R16 [paragraph.3.3.1.6]
[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:
GPO Item Account Right
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)

A Delegation is granted to Everyone

Rule ID:

P-DelegationEveryone

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

15 points per discovery

Documentation:

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

Details:

The detail can be found in Delegations

DN delegation right
DC=test,DC=mysmartlogon,DC=com Everyone GenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
OU=TestOU,DC=test,DC=mysmartlogon,DC=com Everyone READ_PROP_ms-mcs-admpwd
+ 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]
[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

Details:

The detail can be found in GPO Login script

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

Check if all DC have no constrained delegation.

Rule ID:

P-DelegationDCa2d2

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

25 points per discovery

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controller Delegate Identifier
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" (and are not member 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 has 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). Please note that there is a section bellow in this report named "Admin Groups" which give more information.

Points:

20 points if present

Documentation:

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

Details:

The detail can be found in Admin Groups

+ 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 delegations for the recipient's existence

Rule ID:

P-UnkownDelegation

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

15 points if present

Documentation:

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

Details:

The detail can be found in Delegations

DN delegation right
CN=Users,DC=test,DC=mysmartlogon,DC=com S-1-5-21-4005144719-3948538632-2546531719-1115 WRITE_PROP_MEMBER, VAL_WRITE_SELF_MEMBERSHIP, EXT_RIGHT_FORCE_CHANGE_PWD
+ 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 an SIDHistory attribute using the command: get-ADObject -ldapfilter "(sidhistory=*)" -properties sidhistory.
Each security descriptor of the domain (including file shares for example) should be reviewed to be rewritten with the new SID of the account. Then, the attribute can be removed of these accounts using the migration tool or a PowerShell snippet Remove-SIDHistory once the migration is completed. Please note that once the SID History has been removed, it cannot be added back again without doing a real migration. Hopefully hacking tools such as mimikatz can be used to undo a deletion with for example the lsadump::dcshadow attack.

Points:

5 points per discovery with a minimal of 15 points

Documentation:

[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

SID Object(s)
S-1-5-18 1
+ 15 Point(s)

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

Rule ID:

S-PwdLastSet-90

Description:

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

Technical explanation:

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

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

Advised solution:


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

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

Points:

15 points if present

Documentation:

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

Details:

The detail can be found in Computer information

Computer Creation LastUsed LastChange
WIN-1MLHM2RAF4U$ 3/3/2012 6:24:33 PM 5/21/2020 3:17:08 PM 2/15/2019 7:19:05 PM
WIN-3RC77Q4T0SP$ 3/22/2019 9:30:21 PM 12/1/2019 1:01:52 PM 5/8/2019 12:28:21 PM
DESKTOP-RLP9BES$ 3/23/2019 6:38:12 AM 6/16/2020 5:46:39 PM 3/23/2019 7:38:12 AM
+ 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:

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

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 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 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 [10]

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

Advised solution:

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

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

GPO Account Privilege
Default Domain Controllers Policy Everyone SeInteractiveLogonRight
Default Domain Controllers Policy Authenticated Users SeInteractiveLogonRight
Default Domain Controllers Policy Authenticated Users SeRemoteInteractiveLogonRight
+ 15 Point(s)

Check if Service Accounts are domain administrators

Rule ID:

P-ServiceDomainAdmin

Description:

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

Technical explanation:

"Service Accounts" can imply a high security risk as their password are stored in clear text in the LSA database, which can then be easily exploited using Mimikatz or Cain&Abel for instance. In addition, their passwords don't change and can be used in kerberoast attacks.

Advised solution:

To mitigate the security risk, it is strongly advised to lower the privileges of the "Service Accounts", meaning that they should be removed from the "Domain Administrator" group, while ensuring that the password of each and every "Service Account" is higher than 20 characters

Points:

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

Documentation:

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

Details:

The detail can be found in Admin Groups

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

Advised solution:

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

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

Advised solution:

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

Points:

10 points if present

Documentation:

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

Details:

The detail can be found in Admin Groups

+ 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 controller Owner
CN=ADIANT-A7B9AAC6,CN=Computers,DC=test,DC=mysmartlogon,DC=com TEST\Administrator
+ 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

Account Creation LastChanged
wrongaccount8 2016-03-28 10:40:52Z 2016-03-28 12:40:52Z
teste ( 2017-01-09 18:07:43Z Never
wrongAccount5 2015-06-26 15:47:18Z Never
wrongAccount1 2015-06-26 10:20:33Z Never
+ 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-$$$ such as TEST-$$$ for the TEST domain.

Advised solution:

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

Points:

5 points if present

Documentation:

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

+ 5 Point(s)

Check if the Dns Admins group is not empty

Rule ID:

P-DNSAdmin

Description:

The purpose is to ensure that the Dns Admin 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:

You should remove the members of the DNS admin 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:

5 points if present

Documentation:

https://medium.com/@esnesenon/feature-not-bug-dnsadmin-to-dc-compromise-in-one-line-a0f779b8dc83
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/007efcd2-2955-46dd-a59e-f83ae88f4678
[FR]ANSSI - DnsAdmins group members (vuln1_dnsadmins)1
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

Details:

The detail can be found in Admin Groups

Informative rule

Check that operators group are empty

Rule ID:

P-OperatorsEmpty

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

[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

Group Members
Account Operators 1
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 Protected Users group.

Technical explanation:

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[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

Details:

The schema version is indicated in Domain Information

Update Software

Mitre Att&ck - Mitigation - Update Software [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 be patched as well in these 6 monthes

Technical explanation:

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

Advised solution:

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

Points:

15 points if present

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controller Reason
ADIANT-A7B9AAC6 LastComputerLogonDate=11/9/2018 7:29:04 AM
+ 5 Point(s)

Obsolete OS (Windows 2008)

Rule ID:

S-OS-2008

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

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

Rule ID:

S-DC-2008

Description:

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

Technical explanation:

The OS Windows 2008 is not supported anymore by Microsoft (except when migrated to Azure) and any vulnerability found will not be patched unless an expensive support contrat has been purchased.

Advised solution:

To resolve this security risk, the only way is to decommission DC running Windows 2008 OS, in order to use new versions that are more secured 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

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.

Advised solution:

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

Points:

10 points if present

Documentation:

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 powerfull privileges.
While an active Domain Controller change its password every 30 days, an inactive account can be involved in a domain compromise.
Indeed, another account, which have 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 - Recommandations de sécurité relatives à Active Directory - R45 [paragraph.3.6.6.2]
[FR]ANSSI - Inactive domain controllers (vuln1_password_change_inactive_dc)1

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)

SIDHistory check

Rule ID:

S-SIDHistory

Description:

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

Technical explanation:

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

Advised solution:

To solve the security issue, you should remove all the SIDHistory attributes. To do so, you can list the objects having an SIDHistory attribute using the command: get-ADObject -ldapfilter "(sidhistory=*)" -properties sidhistory.
Each security descriptor of the domain (including file shares for example) should be reviewed to be rewritten with the new SID of the account. Then, the attribute can be removed of these accounts using the migration tool or a PowerShell snippet Remove-SIDHistory once the migration is completed. Please note that once the SID History has been removed, it cannot be added back again without doing a real migration. Hopefully hacking tools such as mimikatz can be used to undo a deletion with for example the lsadump::dcshadow attack.

Points:

5 points per discovery with a minimal of 15 points

Documentation:

[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

SID Object(s)
S-1-5-18 1
+ 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 if all computers have changed their passwords in the last 3 months.

Rule ID:

S-PwdLastSet-90

Description:

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

Technical explanation:

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

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

Advised solution:


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

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

Points:

15 points if present

Documentation:

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

Details:

The detail can be found in Computer information

Computer Creation LastUsed LastChange
WIN-1MLHM2RAF4U$ 3/3/2012 6:24:33 PM 5/21/2020 3:17:08 PM 2/15/2019 7:19:05 PM
WIN-3RC77Q4T0SP$ 3/22/2019 9:30:21 PM 12/1/2019 1:01:52 PM 5/8/2019 12:28:21 PM
DESKTOP-RLP9BES$ 3/23/2019 6:38:12 AM 6/16/2020 5:46:39 PM 3/23/2019 7:38:12 AM
+ 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 be patched as well in these 6 monthes

Technical explanation:

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

Advised solution:

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

Points:

15 points if present

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controller Reason
ADIANT-A7B9AAC6 LastComputerLogonDate=11/9/2018 7:29:04 AM
+ 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.

Advised solution:

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

Points:

10 points if present

Documentation:

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)

DC Vulnerability (SMB v1)

Rule ID:

S-SMB-v1

Description:

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

Technical explanation:

The SMB downgrade attack is used to obtain credentials or executing commands on behalf of a user by using SMB v1 as protocol. Indeed, because SMB v1 supports old authentication protocol, the integrity can be bypassed

Advised solution:

It is highly recommended by Microsoft to disable SMB v1 whenever it is possible on both client and server side. Do note that if you are still not following best practices regarding the usage of deprecated OS (Windows 2000, 2003, XP, CE), regarding Network printer using SMBv1 scan2shares functionalities, or regarding software accessing Windows share with a custom implementation relying on SMB v1, you should consider fixing this issues before disabling SMB v1, as it will generates additional errors.

Points:

10 points if present

Documentation:

https://github.com/lgandx/Responder-Windows
https://blogs.technet.microsoft.com/josebda/2015/04/21/the-deprecation-of-smb1-you-should-be-planning-to-get-rid-of-this-old-smb-dialect
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-2016-ACT-039
[FR]ANSSI CERTFR-2017-ACT-019

Details:

The detail can be found in Domain controllers

Domain controller
WIN-PGAHI2ECI8E
+ 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
[MITRE]T1207 Rogue Domain Controller
[FR]ANSSI - Domain controllers in inconsistent state (vuln1_dc_inconsistent_uac)1

Details:

The detail can be found in Domain controllers

Domain controller Problem
ADIANT-A7B9AAC6 InvalidUserAccount NoConfiguration
+ 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 powerfull privileges.
While an active Domain Controller change its password every 30 days, an inactive account can be involved in a domain compromise.
Indeed, another account, which have 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 - Recommandations de sécurité relatives à Active Directory - R45 [paragraph.3.6.6.2]
[FR]ANSSI - Inactive domain controllers (vuln1_password_change_inactive_dc)1

Details:

The detail can be found in Domain controllers

Domain controller
ADIANT-A7B9AAC6
+ 5 Point(s)

Obsolete Domain Controller (Windows 2008)

Rule ID:

S-DC-2008

Description:

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

Technical explanation:

The OS Windows 2008 is not supported anymore by Microsoft (except when migrated to Azure) and any vulnerability found will not be patched unless an expensive support contrat has been purchased.

Advised solution:

To resolve this security risk, the only way is to decommission DC running Windows 2008 OS, in order to use new versions that are more secured 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)

Obsolete OS (Windows 2008)

Rule ID:

S-OS-2008

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

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)

Check if all admin accounts do support kerberos pre-authentication

Rule ID:

S-NoPreAuthAdmin

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

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

Account Created LastLogon
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

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

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

Advised solution:

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

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

GPO Account Privilege
Default Domain Controllers Policy Everyone SeInteractiveLogonRight
Default Domain Controllers Policy Authenticated Users 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:
GPO Item Account Right
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]
[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

Details:

The detail can be found in GPO Login script

Script Account Right
test.ps1 Authenticated Users Modify, Synchronize
\\test.mysmartlogon.com\sysvol\test.mysmartlogon.com\bin\test.ps1 Authenticated Users Modify, Synchronize
+ 30 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" and to "Authenticated Users"

Technical explanation:

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

Advised solution:

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

Points:

15 points per discovery

Documentation:

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

Details:

The detail can be found in Delegations

DN delegation right
DC=test,DC=mysmartlogon,DC=com Everyone GenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
OU=TestOU,DC=test,DC=mysmartlogon,DC=com Everyone READ_PROP_ms-mcs-admpwd
+ 25 Point(s)

Check if all DC have no constrained delegation.

Rule ID:

P-DelegationDCa2d2

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

25 points per discovery

Documentation:

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

Details:

The detail can be found in Domain controllers

Domain controller Delegate Identifier
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 anonymous, everyone, authenticated users, domain users, domain computers and builtin-users groups.

Advised solution:

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

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" (and are not member 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 has 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). Please note that there is a section bellow in this report named "Admin Groups" which give more information.

Points:

20 points if present

Documentation:

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

Details:

The detail can be found in Admin Groups

+ 15 Point(s)

Check delegations for the recipient's existence

Rule ID:

P-UnkownDelegation

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

15 points if present

Documentation:

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

Details:

The detail can be found in Delegations

DN delegation right
CN=Users,DC=test,DC=mysmartlogon,DC=com S-1-5-21-4005144719-3948538632-2546531719-1115 WRITE_PROP_MEMBER, VAL_WRITE_SELF_MEMBERSHIP, EXT_RIGHT_FORCE_CHANGE_PWD
+ 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 any GPO which disable this password prompt.

Advised solution:

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

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 are domain administrators

Rule ID:

P-ServiceDomainAdmin

Description:

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

Technical explanation:

"Service Accounts" can imply a high security risk as their password are stored in clear text in the LSA database, which can then be easily exploited using Mimikatz or Cain&Abel for instance. In addition, their passwords don't change and can be used in kerberoast attacks.

Advised solution:

To mitigate the security risk, it is strongly advised to lower the privileges of the "Service Accounts", meaning that they should be removed from the "Domain Administrator" group, while ensuring that the password of each and every "Service Account" is higher than 20 characters

Points:

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

Documentation:

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

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

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

Advised solution:

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

Points:

5 points per discovery

Documentation:

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

Details:

The detail can be found in Admin Groups

Group User
Administrators Adiant
Domain Administrators Adiant
Schema Administrators Adiant
+ 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

Account Creation LastChanged
wrongaccount8 2016-03-28 10:40:52Z 2016-03-28 12:40:52Z
teste ( 2017-01-09 18:07:43Z Never
wrongAccount5 2015-06-26 15:47:18Z Never
wrongAccount1 2015-06-26 10:20:33Z Never
+ 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 controller Owner
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 to remove this group membership.

Advised solution:

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

Points:

10 points if present

Documentation:

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

Details:

The detail can be found in Admin Groups

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

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

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

Check if the Dns Admins group is not empty

Rule ID:

P-DNSAdmin

Description:

The purpose is to ensure that the Dns Admin 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:

You should remove the members of the DNS admin 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:

5 points if present

Documentation:

https://medium.com/@esnesenon/feature-not-bug-dnsadmin-to-dc-compromise-in-one-line-a0f779b8dc83
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/007efcd2-2955-46dd-a59e-f83ae88f4678
[FR]ANSSI - DnsAdmins group members (vuln1_dnsadmins)1
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

Details:

The detail can be found in Admin Groups

Informative rule

Check that operators group are empty

Rule ID:

P-OperatorsEmpty

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

[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

Group Members
Account Operators 1
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.

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]
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[FR]ANSSI - Accounts or groups with SID history set (vuln3_sidhistory_present)3

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

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

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

Advised solution:

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

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

Points:

100 points if the occurence is greater 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
[MITRE]T1134.005 Access Token Manipulation: SID-History Injection
[FR]ANSSI - Outbound forest trust relationships with sID History enabled (vuln1_trusts_forest_sidhistory)1
[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 - Recommandations de sécurité relatives à Active Directory - R16 [paragraph.3.3.1.6]
[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 being changed and that there was either a problem with the remote domain or that the remote domain does not exist anymore.

Advised solution:

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

Points:

20 points if present

Documentation:

https://msdn.microsoft.com/fr-fr/library/ms680921(v=vs.85).aspx
[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
+ 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-$$$ such as TEST-$$$ for the TEST domain.

Advised solution:

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

Points:

5 points if present

Documentation:

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

050100

Anomalies : 100 /100

It is about specific security control points

+ 60 Point(s)

Find Password GPO

Rule ID:

A-PwdGPO

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

20 points per discovery

Documentation:

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

Details:

The detail can be found in the Obfuscated Passwords

GPO login password
test nfc 2 administrator vletoux
test nfc 2 adiant vletoux
test nfc 2 test test
+ 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 Card to protected sensitive account is a good thing. Nevertheless, when the "Smart Card required" flag is set, the password of the account is not changed anymore by default. Internally the hash of this password is used to sign the user's kerberos tickets, making this account vulnerable to Silver ticket attacks. The rule is triggered 90 days after the last change of the attribute unicodePwd. This value is collected using the replication metadata of the attribute 589914

Advised solution:

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

Points:

30 points if present

Documentation:

https://blogs.technet.microsoft.com/positivesecurity/2017/05/17/smartcard-and-pass-the-hash/
[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.
[MITRE]T1110.002 Brute Force: Password Cracking
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R38 [paragraph.3.6.2.2]

Details:

The detail can be found in Smart Card and Password

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

Advised solution:

The password of the krbtgt account should be changed twice to invalidate the golden ticket attack.
Beware: two changes of the krbtgt password not replicated to domain controllers can break these domain controllers You should wait at least 8 hours between each krbtgt password change.

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

Points:

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

Documentation:

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

Details:

The detail can be found in Krbtgt

+ 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 certificate on behalf 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 enrollement 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/
[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 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

Advised solution:

Review the security permissions of this certificate template and remove the write access to everyone-like group such as domain user, 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

Details:

The detail can be found in Certificate Templates

Name
CopyofCopyofEnrollmentAgent2
CopyofCopyofCopyofCopyofEnrollmentAgen4
+ 15 Point(s)

Check for the last backup date according to Microsoft standard

Rule ID:

A-BackupMetadata

Description:

The purpose is check if the backups are actually up to date in case they are needed. The alert can be triggered when a domain is backed up using non-recommended methods

Technical explanation:

A verification is done on the backups, ensuring that the backup is performed according to Microsoft standards. Indeed at each backup the DIT Database Partition Backup Signature is updated.  If for any reasons, backups are needed to perform a rollback (rebuild a domain) or to track past changes, the backups will actually be up to date. This check is equivalent to a REPADMIN /showbackup *.

Advised solution:

Plan AD backups based on Microsoft standards. These standards depend on the Operating System. For example with the wbadmin utility: wbadmin start systemstatebackup -backuptarget:d:

Points:

15 points if the occurence is greater 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 depends 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

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

Check the if a custom subject can be pushed on an authentication certificate templates

Rule ID:

A-CertTempCustomSubject

Description:

The purpose of this rule is to ensure that there is no certificate request having an authentication purpose whose subject can be modified

Technical explanation:

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

Advised solution:

On the certificate template properties, uncheck in the property sheet "Subject Name" the field "Supply in the request".
Or in alternative, restrict this template to a restricted 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/
[MITRE]T1558 Steal or Forge Kerberos Tickets

Details:

The detail can be found in Certificate Templates

Name
SmartcardLogonforKSP
SubCA
+ 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 anyone

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 other users and impersonate them using it.

Advised solution:

Review the permissions that allow a wide enrollement 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/
[MITRE]T1558 Steal or Forge Kerberos Tickets

Details:

The detail can be found in Certificate Templates

Name
SubCA
+ 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 represents a high risk because they can fairly easily be brute-forced. Most CERT and agencies advises for at least 8 characters (and often this number goes up to 12)

Advised solution:

To solve the issue, the best way is to either remove the GPO enabling short password, or to modify it in order to increase the password length to at least 8 characters

Points:

10 points if present

Documentation:

https://www.microsoft.com/en-us/research/publication/password-guidance/
[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
Default Domain Policy
Test GPO site
Default Domain Controllers Policy
+ 10 Point(s)

Retrieve data from the domain without any account

Rule ID:

A-NullSession

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

10 points if present

Documentation:

https://www.sans.org/reading-room/whitepapers/windows/null-sessions-nt-2000-286
[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 if LDAPS is used with weak SSL protocol.

Rule ID:

A-DCLdapsProtocol

Description:

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

Technical explanation:

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

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

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

Advised solution:

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

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

DC Protocol
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 collect the right set of events.

Technical explanation:

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

Advised solution:

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 GPO for a given domain controller.

Type Audit Problem Rationale Domain 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
+ 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 explicitly disabled.

Technical explanation:

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

Advised solution:

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

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 for GPO enabling the unsafe algorithm LM hash

Rule ID:

A-LMHashAuthorized

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

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

Details:

The detail can be found in Security settings

GPO Setting
Default Domain Policy NoLMHash
+ 5 Point(s)

Check if LAPS passwords can be retrieved from computers that has 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 for Windows 2000 compatibility which allows access to the domain without any account

Rule ID:

A-PreWin2000Anonymous

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

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

+ 2 Point(s)

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

Rule ID:

A-PreWin2000Other

Description:

The purpose is check 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 Intermediate Certificates using unsafe hashing algorithm (SHA1)

Rule ID:

A-SHA1IntermediateCert

Description:

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

Technical explanation:

The SHA1 hashing algorithm is not considered as safe. There are design flaws inherent to the algorithm that allow an attacker to generate a hash collision in less than a brute-force time

Advised solution:

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

Points:

1 points if present

Documentation:

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

Details:

The detail can be found in Certificates

GPO Subject
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
+ 1 Point(s)

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

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

Details:

The detail can be found in Certificates

Source Subject Module Expires
GPO:Default Domain Policy;Machine CN=CA, DC=test, DC=mysmartlogon, DC=com 2048 2030-10-02 09:44:04Z
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=CA, DC=test, DC=mysmartlogon, DC=com 2048 2030-10-02 09:44:04Z
NTLMStore CN=DOD EMAIL CA-29, C=US, O=U.S. Government, OU=DoD, OU=PKI 2048 2041-09-15 09:08:21Z
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 attribute unixUserPassword and userPassword should be cleared from the mentionned user account, unless the remote system is known to have a strong cryptographic protocol.

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Unix Passwords

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 Protected Users group.

Technical explanation:

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[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

Details:

The schema version is indicated in Domain Information

Informative rule

Check for Root Certificates using unsafe hashing algorithm (SHA1)

Rule ID:

A-SHA1RootCert

Description:

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

Technical explanation:

The SHA1 hashing algorithm is not considered as safe. There are design flaws inherent to the algorithm that allow an attacker to generate a hash collision in less than a brute-force time

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://tools.ietf.org/html/rfc6194
[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

GPO Subject
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 that the "Pre-Windows 2000 Compatible Access" group does not contain "Authenticated Users"

Rule ID:

A-PreWin2000AuthenticatedUsers

Description:

The purpose is check 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 on the exploitation vulnerability on legacy protocols such as the printer spooler.
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
[MITRE]T1210 Exploitation of Remote Services

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 recommandations:
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 if there is powershell logging enabled.

Rule ID:

A-AuditPowershell

Description:

The purpose is to ensure that Powershell logging is enabled.

Technical explanation:

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

Advised solution:

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

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

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 behind Kerberoast attack (offline crack 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 Account.

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Password Policies

This section shows the main technical characteristics of the domain.

Domain Netbios Name Domain Functional Level Forest Functional Level Creation date DC count Schema version Recycle Bin enabled
test.mysmartlogon.com TEST Windows Server 2008 R2 Windows Server 2008 R2 2012-03-03 18:12:40Z 2 Windows Server 2008 R2 TRUE

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.

[2]
Name Creation Last logon Distinguished name
HoneyPot Access Denied Never CN=Honey Pot,CN=Users,DC=test,DC=mysmartlogon,DC=com
HoneyPotInexistant Access Denied Never

Account analysis

Nb User Accounts Nb 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 ?
23 21 2 2 19 0 5 3 0 0 0 0 0
[19]
Name Creation Last logon Distinguished name
123456789 Access Denied Never CN=tata yoyo.123456789,CN=Users,DC=test,DC=mysmartlogon,DC=com
ADHealthCheck$ 2016-12-03 10:22:26Z Never CN=ADHealthCheck,CN=Managed Service Accounts,DC=test,DC=mysmartlogon,DC=com
Administrator 2012-03-03 18:13:00Z 2020-03-02 18:58:06Z CN=Administrator,CN=Users,DC=test,DC=mysmartlogon,DC=com
BlueHat Access Denied Never CN=BlueHat,CN=Users,DC=test,DC=mysmartlogon,DC=com
HINSON Access Denied Never CN=Kimberly Hinson,CN=Users,DC=test,DC=mysmartlogon,DC=com
min Access Denied Never CN=min,CN=Users,DC=test,DC=mysmartlogon,DC=com
minobj Access Denied Never CN=minobj,CN=Users,DC=test,DC=mysmartlogon,DC=com
NullDACL Access Denied Never CN=Null DACL,CN=Users,DC=test,DC=mysmartlogon,DC=com
test2 2019-03-23 07:19:15Z 2020-01-12 14:26:14Z CN=test2,CN=Users,DC=test,DC=mysmartlogon,DC=com
testitb1 2019-04-06 11:31:38Z 2019-04-06 13:33:30Z CN=testitb,CN=Builtin,DC=test,DC=mysmartlogon,DC=com
tset ☺☻♥♦♣♠•◘○◙♂♀♪♫☼ 2019-10-26 19:20:02Z Never CN=test ☺☻♥♦♣♠•◘○◙♂♀♪♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongAccount1 2015-06-26 10:20:33Z Never CN=wrongAccount1,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongaccount10 Access Denied Never CN=wrongaccount10,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
wrongAccount2 Access Denied Never CN=wrongAccount2,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongAccount5 2015-06-26 15:47:18Z Never CN=wrongAccount5,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
wrongAccount6 Access Denied Never CN=wrongAccount6,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
wrongAccount7 Access Denied Never CN=wrongAccount7,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
wrongaccount8 2016-03-28 10:40:52Z Never CN=wrongaccount8,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongaccount9 Access Denied Never CN=wrongaccount9,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
[5]
Name Creation Last logon Distinguished name
Adiant 2012-03-03 18:13:00Z 2021-07-28 15:19:55Z CN=Adiant,CN=Users,DC=test,DC=mysmartlogon,DC=com
Administrator 2012-03-03 18:13:00Z 2020-03-02 18:58:06Z CN=Administrator,CN=Users,DC=test,DC=mysmartlogon,DC=com
test 2013-03-31 11:33:16Z 2021-07-05 11:52:36Z CN=test,CN=Users,DC=test,DC=mysmartlogon,DC=com
test2 2019-03-23 07:19:15Z 2020-01-12 14:26:14Z CN=test2,CN=Users,DC=test,DC=mysmartlogon,DC=com
testitb1 2019-04-06 11:31:38Z 2019-04-06 13:33:30Z CN=testitb,CN=Builtin,DC=test,DC=mysmartlogon,DC=com
[3]
Name Creation Last logon Distinguished name
BlueHat Access Denied Never CN=BlueHat,CN=Users,DC=test,DC=mysmartlogon,DC=com
test 2013-03-31 11:33:16Z 2021-07-05 11:52:36Z CN=test,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongaccount8 2016-03-28 10:40:52Z Never CN=wrongaccount8,CN=Users,DC=test,DC=mysmartlogon,DC=com
[1]
Name Creation Last logon Distinguished name
wrongaccount8 2016-03-28 10:40:52Z Never CN=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 domain First date seen ? Last date seen ? Count Dangerous SID Found
S-1-5-18 2013-03-31 11:33:16Z 2013-03-31 11:33:16Z 1 True
test.mysmartlogon.com 2016-03-28 10:40:52Z 2016-03-28 10:40:52Z 2 True

Account analysis

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

Nb Computer Accounts Nb Enabled ? Nb Disabled ? Nb Active ? Nb Inactive ? Nb SidHistory ? Nb Bad PrimaryGroup ? Nb unconstrained delegations ? Nb Reversible password ?
10 10 0 2 8 0 1 1 0
[8]
Name Creation Last logon Distinguished name
ADIANT-2CC70D66$ 2013-04-01 09:32:22Z 2013-04-01 11:32:26Z CN=ADIANT-2CC70D66,CN=Computers,DC=test,DC=mysmartlogon,DC=com
ADIANT-A7B9AAC6$ 2013-04-01 10:10:33Z 2018-11-09 07:29:04Z CN=ADIANT-A7B9AAC6,CN=Computers,DC=test,DC=mysmartlogon,DC=com
ADIANT-VIRTUAL-$ 2019-01-27 12:57:02Z 2019-01-27 13:57:02Z CN=ADIANT-VIRTUAL-,CN=Computers,DC=test,DC=mysmartlogon,DC=com
DESKTOP-RLP9BES$ 2019-03-23 06:38:12Z 2020-06-16 17:46:39Z CN=DESKTOP-RLP9BES,OU=Test LAPS,DC=test,DC=mysmartlogon,DC=com
TEST$ 2019-01-27 09:40:38Z 2019-01-27 10:40:41Z CN=TEST,CN=Computers,DC=test,DC=mysmartlogon,DC=com
WIN-1MLHM2RAF4U$ 2012-03-03 18:24:33Z 2020-05-21 15:17:08Z CN=WIN-1MLHM2RAF4U,CN=Computers,DC=test,DC=mysmartlogon,DC=com
WIN-3RC77Q4T0SP$ 2019-03-22 21:30:21Z 2019-12-01 13:01:52Z CN=WIN-3RC77Q4T0SP,CN=Computers,DC=test,DC=mysmartlogon,DC=com
WINDOWS7X86$ 2012-03-03 22:07:05Z 2016-09-15 23:54:27Z CN=WINDOWS7X86,CN=Computers,DC=test,DC=mysmartlogon,DC=com
[3]
Name Creation Last logon Distinguished name
ADIANT-VIRTUAL-$ 2019-01-27 12:57:02Z 2019-01-27 13:57:02Z CN=ADIANT-VIRTUAL-,CN=Computers,DC=test,DC=mysmartlogon,DC=com
CREATOR$ 2021-05-13 07:03:09Z Never CN=Creator$,CN=Computers,DC=test,DC=mysmartlogon,DC=com
TEST$ 2019-01-27 09:40:38Z 2019-01-27 10:40:41Z CN=TEST,CN=Computers,DC=test,DC=mysmartlogon,DC=com
[1]
Name Creation Last logon Distinguished name
ADIANT-A7B9AAC6$ 2013-04-01 10:10:33Z 2018-11-09 07:29:04Z CN=ADIANT-A7B9AAC6,CN=Computers,DC=test,DC=mysmartlogon,DC=com
[1]
Name Creation Last logon Distinguished name
WIN-PGAHI2ECI8E$ 2012-03-03 18:17:15Z 2021-07-28 15:18:59Z CN=WIN-PGAHI2ECI8E,OU=Domain Controllers,DC=test,DC=mysmartlogon,DC=com

Operating Systems

Operating System Nb OS Nb Enabled ? Nb Disabled ? Nb Active ? Nb Inactive ? Nb SidHistory ? Nb Bad PrimaryGroup ? Nb unconstrained delegations ? Nb Reversible password ?
OperatingSystem not set 2 2 0 1 1 0 0 0 0
Ubuntu Desktop Linux 1 1 0 0 1 0 0 0 0
Windows Server 2008 R2 1 1 0 1 0 0 0 1 0
Windows 7 3 3 0 0 3 0 0 0 0
Windows XP 2 2 0 0 2 0 1 0 0
Windows 10 1809 1 1 0 0 1 0 0 0 0

Domain controllers

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

[2]
Domain controller Operating System Creation Date ? Startup Time Uptime Owner ? Null sessions ? SMB v1 ? Remote spooler ? FSMO role ?
WIN-PGAHI2ECI8E Windows 2008 2012-03-03 18:17:15Z 2021-07-17 10:33:23Z 14 days TEST\Domain Admins YES YES NO PDC,
RID pool manager,
Infrastructure master,
Schema master,
Domain naming Master
ADIANT-A7B9AAC6 Windows XP 2013-04-01 10:10:33Z Inactive? TEST\Administrator NO NO NO

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 statictics are available.

Group Name Nb 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 Operators 1 1 0 1 0 0 0 1 0 0
Administrators 6 5 1 4 2 1 1 4 0 0
Backup Operators 0 0 0 0 0 0 0 0 0 0
Certificate Operators 0 0 0 0 0 0 0 0 0 0
Certificate Publishers 0 0 0 0 0 0 0 0 0 0
Dns Admins 1 1 0 1 0 0 0 1 0 0
Domain Administrators 5 4 1 3 2 1 1 3 0 0
Enterprise Administrators 1 1 0 1 1 0 0 0 0 0
Print Operators 3 3 0 2 3 0 0 3 0 0
Replicator 0 0 0 0 0 0 0 0 0 0
Schema Administrators 2 2 0 1 2 0 1 1 0 0
Server Operators 0 0 0 0 0 0 0 0 0 0
[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 ?
Adiant YES YES YES NO NO YES NO 2012-03-03 18:13:00Z 2021-07-28 15:19:55Z 2020-10-04 13:47:50Z NO CN=Adiant,CN=Users,DC=test,DC=mysmartlogon,DC=com
Administrator YES NO YES NO NO NO YES 2012-03-03 18:13:00Z 2020-03-02 18:58:06Z 2021-07-11 13:09:56Z NO CN=Administrator,CN=Users,DC=test,DC=mysmartlogon,DC=com
test YES YES YES NO NO NO NO 2013-03-31 11:33:16Z 2021-07-05 11:52:36Z 2020-06-15 11:40:01Z NO CN=test,CN=Users,DC=test,DC=mysmartlogon,DC=com
test2 YES NO YES NO NO NO NO 2019-03-23 07:19:15Z 2020-01-12 14:26:14Z 2019-03-23 08:19:15Z NO CN=test2,CN=Users,DC=test,DC=mysmartlogon,DC=com
teste ( NO NO NO NO NO NO YES 2017-01-09 18:07:43Z Not set 1601-01-01 01:00:00Z NO CN=New Object with (dsg,CN=Users,DC=test,DC=mysmartlogon,DC=com
testitb1 YES NO YES NO NO NO NO 2019-04-06 11:31:38Z 2019-04-06 13:33:30Z 2019-04-06 13:31:38Z NO CN=testitb,CN=Builtin,DC=test,DC=mysmartlogon,DC=com
tset ☺☻♥♦♣♠•◘○◙♂♀♪♫☼ YES NO NO NO NO NO NO 2019-10-26 19:20:02Z Not set 1601-01-01 01:00:00Z NO CN=test ☺☻♥♦♣♠•◘○◙♂♀♪♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongAccount1 YES NO NO NO NO NO NO 2015-06-26 10:20:33Z Not set 1601-01-01 01:00:00Z NO CN=wrongAccount1,CN=Users,DC=test,DC=mysmartlogon,DC=com
wrongAccount5 YES NO NO NO YES NO NO 2015-06-26 15:47:18Z Not set 1601-01-01 01:00:00Z NO CN=wrongAccount5,OU=TestOU,DC=test,DC=mysmartlogon,DC=com
wrongaccount8 YES NO NO NO NO NO NO 2016-03-28 10:40:52Z Not set 2016-03-28 12:40:52Z NO CN=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.

[10]
DistinguishedName Account Right
DC=test Everyone GenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
DC=test TEST\Domain Controllers EXT_RIGHT_REPLICATION_GET_CHANGES_ALL
CN=WMIPolicy,CN=System TEST\Group Policy Creator Owners GenericWrite, DSSelf, Write all prop
CN=SOM,CN=WMIPolicy,CN=System TEST\Group Policy Creator Owners GenericWrite, DSSelf, Write all prop
CN=Users S-1-5-21-4005144719-3948538632-2546531719-1115 WRITE_PROP_MEMBER, VAL_WRITE_SELF_MEMBERSHIP, EXT_RIGHT_FORCE_CHANGE_PWD
OU=TestOU Everyone READ_PROP_ms-mcs-admpwd
OU=TestOU TEST\adiant GenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop
OU=TestOU TEST\wrongAccount6 GenericAll, GenericWrite, WriteDacl, WriteOwner, WRITE_PROP_MEMBER, VAL_WRITE_SELF_MEMBERSHIP
OU=TestOU TEST\wrongAccount7 EXT_RIGHT_FORCE_CHANGE_PWD
OU=TestOU TEST\wrongaccount9 EXT_RIGHT_FORCE_CHANGE_PWD

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 ?
Critical YES 5 2 50
High NO 0 0 0
Medium YES 1 1 0
Other YES 1 1 0

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 statictics are available.

Group or user account ? Priority ? Number of users member of the group ? Number of computer member of the group ? Number of object having indirect control ? Number of unresolved members (removed?) ? Link with other domains Detail
Account Operators High 1 (Details) 0 0 0 None Analysis
Administrator Critical 1 (Details) 0 None Analysis
Administrators Critical 6 (Details) 0 1 (Details) 0 None Analysis
Backup Operators High 0 0 0 0 None Analysis
Certificate Operators Medium 0 0 0 0 None Analysis
Certificate Publishers Other 0 1 (Details) 1 including EVERYONE (Details) 0 None Analysis
Dns Admins Medium 1 (Details) 0 0 0 None Analysis
Domain Administrators Critical 5 (Details) 0 2 (Details) 0 None Analysis
Enterprise Administrators Critical 1 (Details) 0 0 0 None Analysis
Print Operators Medium 3 (Details) 0 0 0 None Analysis
Replicator Medium 0 0 0 0 None Analysis
Schema Administrators Critical 2 (Details) 0 1 (Details) 0 None Analysis
Server Operators High 0 0 0 0 None Analysis

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 statictics are available.

Group or user account ? Priority ? Number of users member of the group ? Number of computer member of the group ? Number of object having indirect control ? Number of unresolved members (removed?) ? Link with other domains Detail
Builtin OU Medium 0 0 None Analysis
Certificate store Medium 0 0 None Analysis
Computers container Medium 0 0 None Analysis
Domain Controllers Critical 0 2 (Details) 2 including EVERYONE (Details) 0 None Analysis
Domain Root Medium 1 including EVERYONE (Details) 0 None Analysis
Enterprise Read Only Domain Controllers Other 0 0 0 0 None Analysis
Group Policy Creator Owners Medium 1 (Details) 0 0 0 None Analysis
Krbtgt account Medium 0 0 None Analysis
Read Only Domain Controllers Medium 0 0 0 0 None Analysis
Users container Medium 0 0 None Analysis