Check the process of registration of computers to the domain

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

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.

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

10 points if present

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

Check for completeness of network declaration

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

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

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

5 points if present

The detail can be found in Domain controllers

At least one Administrator Account can be delegated

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

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.

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

20 points if present

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

The detail can be found in Admin Groups

Check for Native administrator usage

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

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

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

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

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

20 points if the occurence is strictly lower than 35

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

Avoid unexpected schema modifications which could result in domain rebuild

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

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.

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

10 points if present

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

The detail can be found in Admin Groups

Ensure that the Recycle Bin feature is enabled

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

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

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

10 points if present

The detail can be found in Domain Information

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

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

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

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

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

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

5 points if present

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

The detail can be found in Delegations

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

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

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

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

15 points if present

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

The detail can be found in LAPS

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

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

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.

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

10 points if present

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

The detail can be found in Audit settings

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

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

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

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

10 points if present

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

The detail can be found in Domain controllers

Check for Short password length in password policy

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

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)

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

10 points if present

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

The detail can be found in Password policies

Ensure that there are enough DCs to provide basic redundancy

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

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

Increase the number of domain controllers by installing new ones.

5 points if the occurence is strictly lower than 2

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

The detail can be found in Domain controllers

Check if there is powershell logging enabled.

The purpose is to ensure that Powershell logging is enabled.

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.

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.

Informative rule (0 point)

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

The detail can be found in Security settings

Check if LLMNR can be used to steal credentials

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

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

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

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

Informative rule (0 point)

https://youtu.be/Fg2gvk0qgjM

The detail can be found in Security settings

Check the Password Policy for Service Accounts (Information)

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)

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.

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.

Informative rule (0 point)

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

The detail can be found in Password Policies