egia.com - Healthcheck analysis

Ensure that the NTLMv1 and old LM protocols are banned

S-OldNtlm

The purpose is to check if NTLMv1 or LM can be used by DC

NTLMv1 is an old protocol which is known to be vulnerable to cryptographic attacks.
It is typically used when a hacker sniffs the network and tries to retrieve NTLM hashes which can then be used to impersonate users.

This attack can be combined with coerced authentication attacks - a hacker forces the DC to connect to a controlled host.
In this case, NTLMv1 can be specified so the hacker can retrieve the NTLM hash of the DC, impersonates it and then take control of the domain.
This attack is still possible with NTLMv2 but this is more difficult.

Windows has default security settings regarding LM/NTLM. Windows XP: Send LM & NTLM responses, Windows Server 2003: Send NTLM response only, Vista/2008: Win7/2008 R2: Send NTLMv2 response only.

However Domain Controllers have relaxed default settings to accept the connection of older operating systems.
That means that by default, NTLMv1 is accepted on domain controllers.
If no GPO defines the LAN Manager Authentication Level, the DC fall back to the non secure default.

After an audit of NTLMv1 usage (see the links below), you need to raise the LAN Manager Authentication Level to "Send NTLMv2 response only. Refuse LM & NTLM".
This can be done by editing the policy "Network security: LAN Manager authentication level" which can be accessed in Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
The policy will be applied after a computer reboot.

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

15 points if present

https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/audit-domain-controller-ntlmv1
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level
https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-ntlm-2-authentication
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R37 [paragraph.3.6.2.1]

The detail can be found in Security settings

Inactive account check

S-Inactive

The purpose is to ensure that there are as few inactive accounts as possible within the domain. Stale user accounts are a significant security issue, as former employees and external attackers could use those accounts to attack the organization.

Inactive accounts often stay in the network because of weaknesses in the decommissioning process. These stale computer accounts can be used as backdoors and therefore represents a possible security breach.

To mitigate the risk, you should monitor the number of inactive accounts and reduce it as much as possible. A list of all inactive accounts is obtainable through the command: Search-ADAccount –AccountInActive –UsersOnly –TimeSpan 180:00:00:00 –ResultPageSize 2000 –ResultSetSize $null | ?{$_.Enabled –eq $True} | Select-Object Name, SamAccountName, DistinguishedName.

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

[MITRE]Mitre Att&ck - Mitigation - User Account Management
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R45 [paragraph.3.6.6.2]
[FR]ANSSI - Dormant accounts (vuln1_user_accounts_dormant)1

The detail can be found in User information and Computer information

Obsolete OS (Windows 10 or Windows 11)

S-OS-W10

The purpose is to ensure that there is no use of non-supported version of Windows 10 or Windows 11 within the domain

Some versions of Windows 10 and Windows 11 OS are no longer supported, and may be vulnerable to exploits that are not patched anymore.

In order to solve this security issue, you should upgrade all the Windows 10 or Windows 11 to a more recent version.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto | where {$_.enabled -eq $true}
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows 1*"}

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

https://docs.microsoft.com/en-us/windows/release-health/release-information
[MITRE]Mitre Att&ck - Mitigation - Update Software
[FR]ANSSI CERTFR-2005-INF-003

The detail can be found in Operating Systems

Obsolete OS (Windows Server 2012)

S-OS-2012

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

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

In order to solve this security issue, you should upgrade all the servers to a more recent version of Windows, starting from Windows Server 2012.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto | where {$_.enabled -eq $true}
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows Server*"}

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

https://learn.microsoft.com/fr-fr/lifecycle/products/windows-server-2012-r2
[MITRE]Mitre Att&ck - Mitigation - Update Software
[FR]ANSSI CERTFR-2005-INF-003

The detail can be found in Operating Systems

Check that there is no account with never-expiring passwords

S-PwdNeverExpires

The purpose is to ensure that every account has a password which is compliant with password expiration policies

Some accounts have passwords which never expire. Should an attacker compromise one of these accounts, he would be able to maintain long-term access to the Active Directory domain.

We have noted that some Linux servers, domain joined, are configured with a password which never expires.
This is a misconfiguration because a password change can be configured. It was however not the default on some plateform.
See one of the link below for more information.

In order to make Active Directory enforce periodic password change, accounts must not have the "Password never expires" flag set in the "Account" tab of the user properties. Their passwords should then be rolled immediately.
For services accounts, Windows provide the "managed service accounts" and "group managed service accounts" features to facilite the automatic change of passwords.
Please note that there is a document in the section below which references solutions for service accounts of well known products.
Also Linux servers should be configured with automatic machine account change.

1 points if present

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

The detail can be found in User information

Obsolete OS (Windows 7)

S-OS-Win7

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

The Windows 7 OS is no longer supported, as it is vulnerable to many publicly known exploits: Administrator's credentials can be captured, security protocols are weak, etc.
PingCastle is trying to guess if Extended Security Support (ESU) has been purchased from Microsoft. Based on the documentation referenced below, the program checks if the script Activate-ProductOnline.ps1 is present.
If the script is detected, Windows 7 is considered as supported and this rule is not triggered.

In order to solve this security issue, you should upgrade all the workstations to a more recent version of Windows, starting from Windows 10.
Use PingCastle.exe and select export on the main menu. Then choose to export computers. PingCastle will produce a list of all your computers with the OS version in a csv file. You can then use Excel to filter them.
Do note that you can get the full details regarding the OS used with the following PowerShell command: Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap -Auto | where {$_.enabled -eq $true}
You can replace -Filter * with -Filter {OperatingSystem -Like "Windows Server*"}

5 points if the occurence is greater than or equals than 15
then 2 points if the occurence is greater than or equals than 6
then 1 points if present

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/activate-windows-7-esus-on-multiple-devices-with-a-mak/ba-p/1167196
[FR]ANSSI CERTFR-2005-INF-003
[MITRE]Mitre Att&ck - Mitigation - Update Software

The detail can be found in Operating Systems

Ensure that DC supports Kerberos armoring when functional level is at least Windows Server 2012

S-KerberosArmoringDC

The purpose is to ensure that DC supports Kerberos armoring when functional level is at least Windows Server 2012

Kerberos Armoring is an optimization of the Kerberos protocol. It avoids the pre-authentication steps and thereby prevents pre-authentication attacks.
It is supported only starting Windows Server 2012 DC and Windows 8 workstations.
If Kerberos Armoring is requested for other operating systems (such as Windows 7 or Linux), the Kerberos authentication protocol may refuse to work.

To enable Kerberos armoring for domain controllers, edit the GPO and go to Computer Configuration > Administrative Templates > System > KDC
then enable the policy "KDC support for claims, compound authentication and Kerberos armoring".
The policy should be set to at least "Supported".

The safest settings is "Fail authentication requests when Kerberos armoring is not available" but it should be enabled only if the clients support Kerberos armoring.

Informative rule (0 point)

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831747(v=ws.11)
https://pupuweb.com/solved-how-enable-kerberos-armoring-eap-fast-ad/
[MITRE]T1558 Steal or Forge Kerberos Tickets

If activated, the detail can be found in Security settings

Ensure that clients support Kerberos armoring when the domain functional level is at least Windows Server 2012

S-KerberosArmoring

The purpose is to ensure that clients support Kerberos armoring when domain functional level is at least Windows Server 2012

Kerberos Armoring is an optimization of the Kerberos protocol. It avoids the pre-authentication steps thus prohibiting pre-authentication attacks;
It is supported only starting Windows Server 2012 DC and Windows 8 workstations.
If Kerberos armoring is requested for other operating systems (such as Windows 7 or Linux), the Kerberos authentication protocol may refuse to work.

To enable Kerberos armoring for client, edit the GPO and go to Computer Configuration > Administrative Templates > System > Kerberos
then enable the policy "Kerberos client support for claims, compound authentication and Kerberos armoring".

Informative rule (0 point)

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831747(v=ws.11)
https://pupuweb.com/solved-how-enable-kerberos-armoring-eap-fast-ad/
[MITRE]T1558 Steal or Forge Kerberos Tickets

If activated, the detail can be found in Security settings

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

S-DefaultOUChanged

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

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.

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

Informative rule (0 point)

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

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

P-ProtectedUsers

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

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.

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

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

https://docs.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/
[FR]ANSSI - Privileged accounts outside of the Protected Users group (vuln3_protected_users)3
[MITRE]Mitre Att&ck - Mitigation - Privileged Process Integrity
[US]STIG V-78131 - Accounts with domain level administrative privileges must be members of the Protected Users group in domains with a domain functional level of Windows 2012 R2 or higher.
[FR]ANSSI CERTFR-2017-ALE-012

The detail can be found in Admin Groups

Check if all admin passwords are changed on the field.

P-AdminPwdTooOld

The purpose is to ensure that all admins are changing their passwords at least every 3 years

This rule ensure that passwords of administrator are well managed.

We advised to read the ANSSI guidelines about this, which is quoted in the documentation section below.

10 points if present

[FR]ANSSI - Privileged account passwords age too old (vuln1_password_change_priv)1
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

The detail can be found in Admin Groups

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

A-LAPS-Not-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
[US]STIG V-36438 - Local administrator accounts on domain systems must not share the same password.
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[FR]ANSSI CERTFR-2015-ACT-046
[MITRE]T1078.003 Valid Accounts: Local Accounts

The detail can be found in LAPS

Check for the last backup date according to Microsoft standard

A-BackupMetadata

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

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

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

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

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

The detail can be found in Backup

RPC interfaces potentially vulnerable to Coerce attacks

A-DC-Coerce

The objective is to assess the vulnerability of the Domain Controller (DC) to Coerce attacks.

Coerce attacks are a category of attacks which aims to forcing domain controllers to authenticate to a device controlled by the attacker for the purpose to relay this authentication to gain privileges.
This category of attacks is usually mitigated by applying patch (PetitPotam), disabling services (Spooler), added RPC filter (EDR or firewall) or ensuring integrity (SMB integrity).
Because each of these protections can be individually bypassed (NTLM integrity is disabled on LDAPS), the aim of this scan is to detect proactively if vulnerable RPC services are exposed.

PingCastle estimates that Coerceable interfaces are protected if:
- the GPO "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" is applied through a GPO to DC
- or if RPC interfaces are not reachable

Because these interfaces need to be tested from a computer controlled by the attacker, PingCastle cannot do this test with reliability.
Instead, it sends a malformed RPC packet to try to trigger an error such as "Permission denied" or "RPC interface unavailable".
If the error RPC_X_BAD_STUB_DATA (1783) is triggered, PingCastle considers that the interface is available.
A report that a vulnerable interface is online may not be accurate because its full exploitation is not tested.

Also to avoid EDR alerts or to not perform the scan, you can run PingCastle with the flag --skip-dc-rpc

To effectively mitigate the vulnerability, consider one of the following approaches:

1. Apply Group Policy Object (GPO) - "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers":
Apply this GPO specifically to the Organizational Unit (OU) "Domain Controllers".
Caution: Enabling this GPO might impact services dependent on NTLM such as files copy Backups.
Consider setting the GPO in "Audit mode" initially to identify and assess the impact on affected services.

2. Enable RPC Filters in Windows Firewall:
Configure Windows Firewall to block specific Interface IDs associated with vulnerable RPC interfaces.
This is done using the netsh command. See the documentation links for more information.
Exercise caution: This method filters the entire interface, not specific Operation Numbers (OpNum).
Adjust exceptions for necessary services to ensure critical functionality.

3. Implement External Filters (e.g., EDR, Firewalls):
Leverage third-party solutions, such as Endpoint Detection and Response (EDR) tools or firewalls.
Notable project: rpcfirewall https://github.com/zeronetworks/rpcfirewall, offering logical filtering at the OpNum level.
Be cautious of potential impact and ensure compatibility with existing infrastructure.

10 points if present

https://github.com/p0dalirius/Coercer
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers
https://blog.nviso.eu/2023/12/08/rpc-or-not-here-we-log-preventing-exploitation-and-abuse-with-rpc-firewall/
[MITRE]T1187 Forced Authentication

The detail can be found in Domain controllers

Ensure that the Print Spooler service cannot be abused to get the DC credentials

A-DC-Spooler

The purpose is to ensure that credentials cannot be extracted from the DC via its Print Spooler service

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 Print 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
[MITRE]T1187 Forced Authentication

The detail can be found in Domain controllers

Ensure that there are enough DCs to provide basic redundancy

A-NotEnoughDC

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
[MITRE]Mitre Att&ck - Mitigation - Data Backup

The detail can be found in Domain controllers

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

A-DsHeuristicsLDAPSecurity

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

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

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

Informative rule (0 point)

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

Check the Password Policy for Service Accounts (Information)

A-NoServicePolicy

The purpose is to give information regarding a best practice for the Service Account password policy. Indeed, having a 20+ characters password for this account greatly helps reducing the risk of Kerberoasting attacks (offline cracking of the TGS tickets)
Note: PSO (Password Settings Objects) will be visible only if the user, which collected the information, has the permission to view it.

The rule is purely informative, as it gives insights regarding a best practice. It verifies if there is a GPO or PSO enforcing a 20+ characters password for the Service Accounts.

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

Informative rule (0 point)

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

The detail can be found in Password Policies

Check if NetCease has been put in place to mitigate Bloodhound

A-NoNetSessionHardening

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

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

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

Informative rule (0 point)

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

The detail can be found in Security settings

Check if Authenticated Users can create DNS records

A-DnsZoneAUCreateChild

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

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.

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.

Informative rule (0 point)

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