Check for hidden group membership for user accounts

The purpose is to check for unsual value in the primarygroupid attribute used to store group membership

In Active Directory, group membersip 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.

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

15 points if present

https://support.microsoft.com/en-us/help/297951/how-to-use-the-primarygroupid-attribute-to-find-the-primary-group-for

The detail can be found in User information and Computer information

Check for hidden group membership for computer accounts

The purpose is to check for unsual value in the primarygroupid attribute used to store group membership

In Active Directory, group membersip 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.

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

15 points if present

https://support.microsoft.com/en-us/help/297951/how-to-use-the-primarygroupid-attribute-to-find-the-primary-group-for

The detail can be found in User information and Computer information

SIDHistory check

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

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.

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.

5 points per discovery with a minimal of 15 points

ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]

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

S-1-5-18 [1 object(s)]

Check that every account requires a password

The purpose is to ensure that there is every account requires a password

An account can be set without a password if it has the flag "PASSWD_NOTREQD" set as "True" in the "useraccountcontrol" attribute. This represents a high security risk as the account is not protected at all without a password

The best solution to solve the problem is to change the "useraccountcontrol" attribue of all the accounts that have it and that are not used in trusts. If the flag is removed while there is no password set, you will have an error. You can use this to detect accounts without any passwords. Do note that you can manually check all the accounts that need to be worked on using the following powershell command: get-adobject -ldapfilter "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=32))" -properties useraccountcontrol

15 points if present

https://support.microsoft.com/en-us/kb/305144
ANSSI - Recommandations de sécurité relatives à Active Directory - R36 [subsection.3.6]

The detail can be found in User information and Computer information

Obsolete OS (Windows XP)

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

The Windows XP 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.

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

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

ANSSI CERTFR-2005-INF-003

The detail can be found in Operating Systems

Check the processus 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 set up represents a security issue as basic users shouldn't be able to create such accounts, this task being handled by administrators

To solve the issue, the limit number of extra computers that can be registered by a basic user should 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 as 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 found IPv6 addresses and it was not expected, you should disable in addition the protocol IPv6 on the network card.

5 points if present

The detail can be found in Domain controllers

Domain Controller WIN-PGAHI2ECI8E ip address 2a01:cb00:938:5500:7da2:529:c55a:b931

DC Vulnerability (SMB v1)

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

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

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 functionnalities, 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 additionnal errors.

1 points if present

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
ttps://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1,-smbv2,-and-smbv3-in-windows-vista,-windows-server-2008,-windows-7,-windows-server-2008-r2,-windows-8,-and-windows-server-2012
ANSSI CERTFR-2016-ACT-039
BSI M 2.412 Schutz der Authentisierung beim Einsatz von Active Directory
ANSSI CERTFR-2017-ACT-019

The detail can be found in Domain controllers

Domain controller: WIN-PGAHI2ECI8E

Ensure that dangerous privileges are not granted to everyone by GPO

The purpose is to ensure that standard users are not granted dangerous privileges

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 modifiy a service running as local system and startable by all users to a choosen 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 securable 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 absued 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.

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.

15 points per discovery

https://www.romhack.io/slides/RomHack%202018%20-%20Andrea%20Pierini%20-%20whoami%20priv%20-%20show%20me%20your%20Windows%20privileges%20and%20I%20will%20lead%20you%20to%20SYSTEM.pdf
https://www.tarlogic.com/en/blog/abusing-seloaddriverprivilege-for-privilege-escalation/
https://github.com/decoder-it/psgetsystem
ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

The detail can be found in Privileges

GPO: Default Domain Policy Account: Everyone Privilege: SeDebugPrivilege
GPO: Default Domain Policy Account: Everyone Privilege: SeLoadDriverPrivilege
GPO: test nfc 2 Account: Everyone Privilege: SeDebugPrivilege
GPO: test nfc 2 Account: Everyone Privilege: SeLoadDriverPrivilege

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"

Whitout 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 checkbox "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

A Delegation is granted to Everyone

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

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

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

15 points per discovery

ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

The detail can be found in Delegations

DN: DC=test,DC=mysmartlogon,DC=com delegation: Everyone right: GenericAll, GenericWrite, WriteDacl, WriteOwner, All extended right, DSSelf, Write all prop

Ensure that GPO items cannot be modified by any user

The purpose is to ensure that standard users cannot modify GPO

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 potentically lead to the compromise of the domain

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.

15 points per discovery

ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

GPO: Default Domain Controllers Policy Item: \\WIN-PGAHI2ECI8E.test.mysmartlogon.com\sysvol\test.mysmartlogon.com\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\GPT.INI Account: Authenticated Users Right: FullControl

Ensure that all login scripts cannot be modified by any user

The purpose is to ensure that standard users cannot modify login scripts

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 potentically lead to the compromise of the domain

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.

15 points per discovery

ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

The detail can be found in GPO Login script

Script: test.ps1 Account: Authenticated Users Right: Modify, Synchronize

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

At least one Domain controller is not owned correctly

The purpose is to perform a review of which accounts have ownership rights on domain controller and can then modify their permissions

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 compromission can be designed to take control of the domain by including this account.

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 have then a new dialog with an owner tab. Select the owner and change it for the domain administrators group. You’re done (no reboot needed)

10 points if present

The detail can be found in Domain controllers

Domain controller: CN=ADIANT-A7B9AAC6,CN=Computers,DC=test,DC=mysmartlogon,DC=com Owner: TEST\administrator

Check that operators group are empty

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

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

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

Informative rule (0 point)

ANSSI - Recommandations de sécurité relatives à Active Directory - R27 [subsection.3.5]

The detail can be found in Admin Groups

Group: Account Operators Member counts: 1

Check for Trusts whose security is not maximum

The purpose is to check if all trusts are protected using the functionality named SID Filtering

SID Filtering is a mechanism used to block account presenting a SID History property. SID History is used to link to an existing account to another account and can be use to propagage a compromission through trusts. SID Filtering for domain to domain trust is called 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')

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.

100 points if the occurence is greater or equals than 4
then 80 points if the occurence is greater or equals than 2
then 50 points if present

https://msdn.microsoft.com/en-us/library/cc237940.aspx
BSI M 4.314 Sichere Richtlinieneinstellungen für Domänen und Domänen-Controller
STIG V-8538 - Security identifiers (SIDs) must be configured to use only authentication data of directly trusted external or forest trust.
ANSSI - Recommandations de sécurité relatives à Active Directory - R16 [paragraph.3.3.1.6]

The detail can be found in Trusts section

trust without SID Filtering: mil

Check for local backdoor stored in SID History

The purpose is to ensure that accounts are not linked for more privileged accounts in the same domain

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.

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 compromission of the domain.

50 points if present

ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]

Check for inactive trusts

The purpose is to verify that every trust has a remote domain which is active.

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.

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.

20 points if present

https://msdn.microsoft.com/fr-fr/library/ms680921(v=vs.85).aspx

The detail can be found in Trusts section

mil

Check if a migration is in progress

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

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.

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 (sAMAccountNmae=*$$$)

5 points if present

ANSSI - Recommandations de sécurité relatives à Active Directory - R15 [paragraph.3.3.1.5]

Find Password GPO

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

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 password in the GPO has been made public for interoperability reasons, which is why even an encrypted password is compromised. It has been revealed in this page

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.

20 points per discovery

https://msdn.microsoft.com/en-us/library/cc422924.aspx
ANSSI CERTFR-2015-ACT-046

The detail can be found in the Obfuscated Passwords

GPO: test nfc 2 login: administrator password: vletoux
GPO: test nfc 2 login: adiant password: vletoux
GPO: test nfc 2 login: test password: test

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

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, and monitoring it closely often mitigates the risk of golden ticket attacks greatly.

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 recommanded to change the krbtgt password every 40 days. If it not the case, every backups done until the last password change of the krbtgt account can be used to emit Goldent tickets, compromising the entiere 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 also be performed using the former password of the krbtgt account

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

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

https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51
ANSSI CERTFR-2014-ACT-032

The detail can be found in Krbtgt

Check for Accounts using Smart Card with unchanged password for a long time

The purpose is to make sure the requirement of Smart Cards doesn't degrade password rotation

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

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.

30 points if present

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

The detail can be found in Smart Card and Password

Check for the last backup date according to Microsoft standard

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 back up using non recommended methods

A verification is done on the backups, ensuring that the backup is performed according to Microsoft standard. 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 *.

Planify backups based on Microsoft standard. These standards depends on the Operating System. Example with the wbadmin utility: wbadmin start systemstatebackup -backuptarget:d:

15 points if the occurence is greater or equals than 7

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

The detail can be found in Backup

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 provisionning 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
STIG V-36438 - Local administrator accounts on domain systems must not share the same password.
ANSSI CERTFR-2015-ACT-046

The detail can be found in LAPS

Check for suspicious account(s) used in administrator activities

The purpose is to ensure that there is no rogue admin accounts in the Active Directory

A check is performed non-admin accounts in order to identify if they have an attribute admincount set. If they have this attribute, it means that this account, which is not supposed to be admin, has been granted administrator rights in the past. This tipically happens when an administrator gives temporary rights to a normal account, off process.

These accounts should be reviewed, especially in regards with their past activities and have the admincount attribute removed. In order to identify which accounts are detected by this rule, we advise to run a Powershell command that will show you all users having this flag set: get-adobject -ldapfilter "(admincount=1)"
Do not forget to look at the section AdminSDHolder below.

50 points if the occurence is greater or equals than 50
then 45 points if the occurence is greater or equals than 45
then 40 points if the occurence is greater or equals than 40
then 35 points if the occurence is greater or equals than 35
then 30 points if the occurence is greater or equals than 30
then 25 points if the occurence is greater or equals than 25
then 20 points if the occurence is greater or equals than 20
then 15 points if present

https://msdn.microsoft.com/en-us/library/ms675212(v=vs.85).aspx
ANSSI - Recommandations de sécurité relatives à Active Directory - R40 [paragraph.3.6.3.1]

The detail can be found in the AdminSDHolder User List

Retrieve data from the domain without any account

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 reckon operation on the AD, to identify weaknesses

Unless other rules which check for known cause of anonymous access, this rule try 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. But 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].

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 proove the extraction of the data.

10 points if present

https://www.sans.org/reading-room/whitepapers/windows/null-sessions-nt-2000-286
BSI M 2.412 Schutz der Authentisierung beim Einsatz von Active Directory

The detail can be found in Domain controllers and Null Session

DC involved: WIN-PGAHI2ECI8E

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

Found in GPO Default Domain Policy
Found in GPO Default Domain Controllers Policy
Found in GPO test nfc 2
Found in GPO PSO:test

Check for Windows 2000 compatibility which allows access to the domain without any account

The purpose is to identify domains that which allows access without any account because of a pre-Windows 2000 compatibility.

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

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

5 points if present

https://msdn.microsoft.com/en-us/library/cc223672.aspx
BSI M 2.412 Schutz der Authentisierung beim Einsatz von Active Directory
STIG V-8547 - The Anonymous Logon and Everyone groups must not be members of the Pre-Windows 2000 Compatible Access group.

Check for Intermediate Certificates using unsafe hashing algorithm (SHA1)

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

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

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

1 points if present

https://tools.ietf.org/html/rfc6194

The detail can be found in Certificates

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

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

Check for Root Certificates using unsafe hashing algorithm (SHA1)

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

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

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

Informative rule (0 point)

https://tools.ietf.org/html/rfc6194

The detail can be found in Certificates

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

Check for presence of the Protected users group

The purpose is to ensure that the schema has been updated for the creation of Protected Users group.

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.

The Protected Users group is automatically created when a Windows 2012 R2 domain controller is installed and upgraded it as 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

Informative rule (0 point)

https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
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.
ANSSI CERTFR-2017-ALE-012

The schema version is indicated in Domain Information