Incorrect detections for various Stale Objects rules

[ralish]

We're seeing several false positive detections in the Stale Objects category for v3.0.0.0 Beta 1.

The LAN Manager Authentication Level allows the use of NTLMv1 or LM Network security: LAN Manager authentication level is set to Send NTLMv2 response only. Refuse LM & NTLM. Set in a policy linked to the top-level domain object (DC=...).

The Kerberos Armoring is not enabled on client and the functional level is at least Windows 2012 Kerberos client support for claims, compound authentication and Kerberos armoring is set to Enabled. Same policy as above. Domin and forest functional levels are both set to Windows Server 2016.

The Kerberos Armoring is not enabled on DC and the functional level is at least Windows 2012 KDC support for claims, compound authentication and Kerberos armoring is set to Enabled with value Always provide claims. Policy is linked to the Domain Controllers OU. The Fail authentication requests when Kerberos armoring is not available setting is not at this time enabled, but that doesn't appear to yet result in any score penalty.

Usually I'd dive into the source to try and isolate where the problem sits, but it doesn't appear to be available yet. Let me know what other information I can provide to assist.

[ralish]

Addendum: Each of these detections has a "The detail can be found in Security settings" link in the descriptive text, but none of the referenced policy settings are shown under that section (either in a secure or insecure configuration).

[vletoux]

sorry i forgot to push the code. Fixed that

Bug # 1 is already fixed

For kerberos armoring, the program doesn't find anything. I adapted the label to show "if found, ..."

[ralish]

@vletoux Sounds good. Regarding the two Kerberos armoring detections, they each contribute +1 point to the Stale Objects score. If they're not based on an actual detection from the domain analysis (so may be already implemented), I'd suggest they shouldn't impact the net score. Other than that, everything else looked good to me from the runs I've done.

[vletoux]

Is everything fixed with the beta 2?

[ralish]

@vletoux Confirming all fixed. Only remaining suggestion is to reword the two informative Kerberos rules as the current wording strongly suggests to the reader that the two policy settings are not enabled (which may be true, but that's not being tested).

Perhaps something like:

• Verify Kerberos Armoring is enabled on clients and the functional level is at least Windows 2012
• Verify Kerberos Armoring is enabled on DCs and the functional level is at least Windows 2012

[vletoux]

done

[fsacer]

Not sure if it is appropriate to ask here, but it seems related: for the rule S-OldNtlm I get the values GPO:"Windows default without an active GPO",Value:3 with the highest severity (15 points), not sure how this is justified since I don't think that is abusable in any tangible way. For the NTLMv1 downgrade the value has to be 2 or lower from what I've heard.

PS: using version 3.0.0.4

[vletoux]

Please look at the reference documentation : https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level

Level 3 allows LM and NTLM on DC Only level 5 is secure

[fsacer]

yeah I did, the docs suggest level 3 is enough for security from their recommendations, additionally, I haven't seen any research that would suggest a practical abuse is possible with this default setting; most guides suggest a practical attack is possible if the setting is set to 0, 1 or 2.

So maybe the score can be dropped a bit if the setting is set to 3 or higher?

[vletoux]

These guides are out-dated. Réflexion attacks (such as with the print spooler) make a quick exploitation. LM or NTLMv1 protocol is used. Then LM or NTLMv1 hash is brute forced. Then used to connect back.

[vletoux]

https://www.crowdstrike.com/blog/ntlm-keeps-haunting-microsoft/

[fsacer]

Indeed, I've tried these with the setting of 3 and never got NTLMv1 back from DC