Healthcheck analysis

Check the use of Kerberos on services accounts without AES support

Rule ID:

S-AesNotEnabled

Description:

The purpose is to verify that AES is enabled for service accounts. Starting January 2026, Microsoft is phasing out RC4 as the default Kerberos encryption for accounts without explicit encryption type configuration. Accounts flagged by this rule may experience authentication failures after enforcement begins in April 2026.

Technical explanation:

By default, Kerberos uses RC4 encryption, which relies directly on the NTLM hash of the account password. RC4 is considered weak and Microsoft is actively deprecating it in favour of AES (see below).

Accounts are flagged by this rule if:

• Their password has not been changed since the first Windows Server 2008 domain controller was installed, meaning no AES key material has been generated for the account.
• They have a Service Principal Name (SPN) and the msDS-SupportedEncryptionTypes attribute does not include AES (bits 0x8 or 0x10 are not set).

Enabling AES on these accounts is the first step towards removing RC4 dependency. Note that additional checks are required before fully disabling RC4, such as verifying trust account encryption settings. A dedicated section in this report explores AES compatibility.

Microsoft RC4 Deprecation (January 2026)

Microsoft is phasing out RC4 as the default Kerberos encryption in a three-phase rollout:

• Phase 1 (January 2026): Audit mode — new Kerberos events (201, 202, 205-207) allow organisations to identify RC4 dependencies without enforcement changes.
• Phase 2 (April 2026): Enforcement — the default changes to AES-SHA1 (0x18) for accounts without explicit msDS-SupportedEncryptionTypes configuration. Accounts will receive AES encrypted tickets instead of RC4.
• Phase 3 (July 2026): Full enforcement — RC4 becomes available only through explicit per-account configuration.

After enforcement, accounts without AES configured may still work if their environment supports the new defaults, but may also experience authentication failures depending on their configuration and dependencies.

Registry Keys

HKLM\System\CurrentControlSet\services\KDC\DefaultDomainSupportedEncTypes (REG_DWORD) controls the default encryption for accounts without explicit msDS-SupportedEncryptionTypes on the domain controller.

• Recommended value 0x18 (24): AES128 + AES256 (enforcement default)
• Value 0x38 (56): AES128 + AES256 + AES256-SK — for AES-only environments with enforced AES session keys
• Value 0x3C (60): RC4 + AES128 + AES256 + AES256-SK — for backwards compatibility with enforced AES session keys

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\RC4DefaultDisablementPhase (REG_DWORD, requires restart) controls the RC4 deprecation phase on the domain controller. This is a temporary key that will be removed after July 2026.

• 0 = No audit, no change
• 1 = Warning events logged on default RC4 usage (Phase 1 default, January 2026)
• 2 = Kerberos assumes RC4 is not enabled by default (Phase 2 default, April 2026)

msDS-SupportedEncryptionTypes Bitmask Reference

Hex	Decimal	Encryption Types
0x1	1	DES-CBC-CRC
0x2	2	DES-CBC-MD5
0x4	4	RC4-HMAC
0x8	8	AES128-CTS-HMAC-SHA1-96
0x10	16	AES256-CTS-HMAC-SHA1-96
0x20	32	AES256-CTS-HMAC-SHA1-96-SK (enforce AES session keys when RC4 is in use)
0x18	24	AES128 + AES256 (recommended, enforcement default)
0x1C	28	RC4 + AES128 + AES256
0x38	56	AES128 + AES256 + AES256-SK (AES-only with enforced AES session keys)
0x3C	60	RC4 + AES128 + AES256 + AES256-SK (backwards compatible with enforced AES session keys)

Non-Windows Systems

Unix/Linux/macOS machines authenticating via Kerberos will need their krb5.conf updated to permit AES encryption types. Keytabs generated with RC4 encryption will need to be regenerated with AES support. Applications using GSSAPI or native Kerberos libraries should be tested after the transition.

Advised solution:

Enable AES encryption on affected accounts by setting the msDS-SupportedEncryptionTypes attribute. This can be done via the user properties dialog (check "This account supports Kerberos AES 128 bit encryption" and "This account supports Kerberos AES 256 bit encryption") or via PowerShell:

Enable AES 128 and AES 256 on a single user account (value 0x18 = 24):

Set-ADUser -Identity "serviceaccount" -Replace @{"msDS-SupportedEncryptionTypes" = 24}

Enable RC4 + AES 128 + AES 256 (value 0x1C = 28) for backwards compatibility:

Set-ADUser -Identity "serviceaccount" -Replace @{"msDS-SupportedEncryptionTypes" = 28}

For computer accounts:

Set-ADComputer -Identity "COMPUTERNAME" -Replace @{"msDS-SupportedEncryptionTypes" = 28}

For Group Managed Service Accounts (gMSA):

Set-ADServiceAccount -Identity "gmsa$" -Replace @{"msDS-SupportedEncryptionTypes" = 24}

Warning: This command will set the default encryption to AES for all accounts without msDS-SupportedEncryptionTypes configured.

Get-ADObject -LDAPFilter "(&(!(msDS-SupportedEncryptionTypes=*))(|(objectClass=user)(objectClass=computer)(objectClass=msDS-GroupManagedServiceAccount)))" | Set-ADObject -Replace @{"msDS-SupportedEncryptionTypes" = 24}

Before making changes, review Kerberos audit events (201, 202, 205-207) to identify RC4 dependencies. Most accounts will already have AES password hashes if their password has been changed since a Windows Server 2008 or later domain controller was introduced. Only accounts whose password has never been reset on a domain with an AES-capable domain controller will need a password reset to generate AES keys.

Non-Windows Systems (Linux/macOS)

Update the Kerberos configuration in /etc/krb5.conf (or the equivalent path on your distribution) to permit AES encryption. The encryption types can be configured globally in the [libdefaults] section or per-realm in the [realms] section:

default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

Regenerate keytabs with AES encryption. Using ktpass on a Windows domain controller:

ktpass -princ HTTP/server.domain.com@DOMAIN.COM -mapuser serviceaccount -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass * -out server.keytab

Using ktutil on Linux:

ktutil

addent -password -p HTTP/server.domain.com@DOMAIN.COM -k 1 -e aes256-cts-hmac-sha1-96

wkt /etc/krb5.keytab

quit

Points:

10 points if present

Documentation:

https://learn.microsoft.com/en-us/archive/blogs/openspecification/msds-supportedencryptiontypes-episode-1-computer-accounts
https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/what-changed-in-rc4-with-the-january-2026-windows-update-and-why-it-is-important/4504732
https://support.microsoft.com/en-us/topic/kb5021131-how-to-manage-the-kerberos-protocol-changes-related-to-cve-2022-37966-fd837ac3-cdec-4e76-a6ec-86e67501407d
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/6cfc7b50-11ed-4b4d-846d-6f08f0812919
https://support.microsoft.com/en-us/topic/how-to-manage-kerberos-kdc-usage-of-rc4-for-service-account-ticket-issuance-changes-related-to-cve-2026-20833-1ebcda33-720a-4da8-93c1-b0496e1910dc
[FR]ANSSI - Service accounts supported encryption algorithms (vuln3_kerberos_properties_encryption)3
[MITRE]T1558.004 Steal or Forge Kerberos Tickets: AS-REP Roasting

Details:

The detail can be found in User information and Computer information

Check the process of registration of computers to the domain

Rule ID:

S-ADRegistration

Description:

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

Technical explanation:

By default, a basic user can register up to 10 computers within the domain. This default configuration represents a security issue as basic users shouldn't be able to create such accounts and this task should be handled by administrators.

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

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

Advised solution:

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

Points:

10 points if present

Documentation:

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

Verify Terminal Services configuration best practices in GPO

Rule ID:

S-TerminalServicesGPO

Description:

This rule verifies the recommended configuration for Terminal Services.

Technical explanation:

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

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

Advised solution:

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

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

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

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

Rule ID:

S-DefaultOUChanged

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

Verify that Defender ASR mitigations are in place

Rule ID:

S-DefenderASR

Description:

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

Technical explanation:

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

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

Advised solution:

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


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

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Defender ASR

Verify the Default Application for Script File Execution

Rule ID:

S-FolderOptions

Description:

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

Technical explanation:

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

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Folder Options

Verify if there are restrictions for internet connectivity of script engines

Rule ID:

S-FirewallScript

Description:

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

Technical explanation:

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

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

Advised solution:

1) Create Firewall Rules via GPO

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

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

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Firewall configuration

At least one administrator account can be delegated

Rule ID:

P-Delegated

Description:

The purpose is to ensure that all Administrator Accounts have the configuration flag "this account is sensitive and cannot be delegated" (or are members of the built-in group "Protected Users" when your domain functional level is at least Windows Server 2012 R2).

Technical explanation:

Without the flag "This account is sensitive and cannot be delegated" any account can be impersonated by some service account. It is a best practice to enforce this flag on administrators accounts.

Advised solution:

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

Points:

20 points if present

Documentation:

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

Details:

The detail can be found in Admin Groups

Avoid unexpected schema modifications which could result in domain rebuild

Rule ID:

P-SchemaAdmin

Description:

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

Technical explanation:

The group "Schema Admins" is used to give permissions to alter the schema. Once a modification is performed on the schema such as new objects, it cannot be undone. This can result in a rebuild of the domain. The best practice is to have this group empty and to add an administrator when a schema update is required, then remove this group membership.

Advised solution:

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

Points:

10 points if present

Documentation:

[US]STIG V-243502 - 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

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

Rule ID:

P-ProtectedUsers

Description:

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

Technical explanation:

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

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

Advised solution:

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

Points:

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

Documentation:

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

Details:

The detail can be found in Admin Groups

Check if OUs and Containers are protected from accidental deletion.

Rule ID:

P-UnprotectedOU

Description:

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

Technical explanation:

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

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

Advised solution:

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

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

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

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Delegations

Check if AES is enabled on trusts

Rule ID:

T-AlgsAES

Description:

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

Technical explanation:

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

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

Advised solution:

Enable AES on the domain.

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

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

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

Points:

1 points if present

Documentation:

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

Details:

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

Rule ID:

A-AuditDC

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

10 points if present

Documentation:

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

Details:

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

Check for short password length in password policy

Rule ID:

A-MinPwdLen

Description:

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

Technical explanation:

A check is performed to identify if the GPO regarding password policy allows less than 8 characters password. Short passwords represent a high risk because they can fairly easily be brute-forced or password sprayed. Most CERT and agencies advise for at least 8 characters (and often this number goes up to 12)

Advised solution:

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

Points:

10 points if present

Documentation:

https://www.microsoft.com/en-us/research/publication/password-guidance/
[FR]ANSSI - Privileged group members with weak password policy (vuln2_privileged_members_password)2
[MITRE]T1201 Password Policy Discovery

Details:

The detail can be found in Password policies

Hardened Paths weakness

Rule ID:

A-HardenedPaths

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

5 points if present

Documentation:

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

Details:

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

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

Rule ID:

A-PreWin2000Other

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

2 points if present

Documentation:

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/7a76a403-ed8d-4c39-adb7-a3255cab82c5
[FR]ANSSI - Use of the "Pre-Windows 2000 Compatible Access" group (vuln3_compatible_2000_not_default)3
[MITRE]T1110.003 Brute Force: Password Spraying

Details:

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

Rule ID:

A-DsHeuristicsLDAPSecurity

Description:

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

Technical explanation:

The way an Active Directory behaves can be controlled via the attribute DsHeuristics of CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration.
A parameter stored in its attribute and whose value is LDAPAddAutZVerifications and LDAPOwnerModify can be set to modify the mitigatation of CVE-2021-42291.
The KB5008383 has introduced changes to default security descriptor of Computer containers to add audit and limit computer creation without being admin.
Indeed, it is recommended to not let anyone create computer accounts as they can be used to abuse Kerberos or to perform relay attacks.

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

Advised solution:

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

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

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

Check if PowerShell logging is enabled.

Rule ID:

A-AuditPowershell

Description:

The purpose is to ensure that PowerShell logging is enabled.

Technical explanation:

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

https://adsecurity.org/?p=2604
https://learn.microsoft.com/en-us/powershell/scripting/wmf/whats-new/script-logging?view=powershell-6
[US]STIG V-220860 - PowerShell script block logging must be enabled
[MITRE]Mitre Att&ck - Mitigation - Audit

Details:

The detail can be found in Security settings

Check if Authenticated Users can create DNS records

Rule ID:

A-DnsZoneAUCreateChild

Description:

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

Technical explanation:

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

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

Advised solution:

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

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

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

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

Ensure that the rootDse Anonymous Binding is disabled

Rule ID:

A-RootDseAnonBinding

Description:

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

Technical explanation:

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

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

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

Rule ID:

A-PreWin2000AuthenticatedUsers

Description:

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

Technical explanation:

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

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

Advised solution:

Remove "Authenticated Users" from the PreWin2000 group.

Points:

Informative rule (0 point)

Documentation:

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/7a76a403-ed8d-4c39-adb7-a3255cab82c5
https://www.gradenegger.eu/?p=1132
[MITRE]T1210 Exploitation of Remote Services

Check if NetCease has been put in place to mitigate Bloodhound

Rule ID:

A-NoNetSessionHardening

Description:

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

Technical explanation:

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

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

Advised solution:

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

Points:

Informative rule (0 point)

Documentation:

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

Details:

The detail can be found in Security settings