This can be seen in practice, if I take a basic minimalist DC and disable the default domain controller policy, I end up with an empty GPPRightAssignment section in my XML:
The finding is not detected my PingCastle, but I still can create machine accounts using a low level user:
It would be possible to make a more rigorous check, and verify if GPOs defining "SeMachineAccountPrivilege" are applied to Domain Controller, but that could be difficult if GPO is applied to an OU that contains DCs, or a OU that contains an OU that contains DCS ....
The current health-check verifies if any GPO gives the SeMachineAccountPrivilege privilege to "Authenticated Users" or other low privileged groups.
There is an edge case however that is not checked: when no GPO defines this privilege. In fact, if no GPO defines the "Add workstations to domain" setting, Windows will take the default value which is "Authenticated Users" according to MS documentation https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.
This can be seen in practice, if I take a basic minimalist DC and disable the default domain controller policy, I end up with an empty GPPRightAssignment section in my XML:
The finding is not detected my PingCastle, but I still can create machine accounts using a low level user:
It would be possible to make a more rigorous check, and verify if GPOs defining "SeMachineAccountPrivilege" are applied to Domain Controller, but that could be difficult if GPO is applied to an OU that contains DCs, or a OU that contains an OU that contains DCS ....