False positive for Rule ID S-Vuln-MS17_010

[jffroment]

When running PingCastle with the latest version 3.5.0.44 in privileged mode in a domain where all domain controllers are patched and up to date, the rule S-Vuln-MS17_010 matches.
I was able to check with nmap that this DC is not vulnerable to this CVE, so I think that this false positive is a bug from the latest pingcastle version

[jffroment]

Root cause analysis

I was able to reproduce and diagnose this false positive on my environment:

• OS: Windows Server 2016
• Real build: 14393.8957 (fully patched, well above the 14393.953 threshold)
• PingCastle version: 3.5.0.44, privileged mode

Why the false positive occurs

Since 3.5.0.37, S-Vuln-MS17_010 uses Win32_QuickFixEngineering (WMI)
to look for specific hotfix IDs (e.g. KB4013429) on each DC.

On Server 2016, the MS17-010 fix was first included in KB4013429 (March 2017 CU),
but this KB has since been superseded. If KB4013429 is not individually listed in WMI
but any later Cumulative Update is installed, the system is protected and the rule
should not trigger.

Exact location of the bug

The issue is in PingCastleCommon/Scanners/SmbHotFixVulnerabilityScanner.cs,
in the hardcoded KB list:

private static readonly string[] Ms17010KBs =
{
"KB4012598",
"KB4012212",
"KB4012213",
"KB4012214",
"KB4012215",
"KB4012216",
"KB4012217",
"KB4012606",
"KB4013389",
"KB4013429",
};

All these KBs are the **original standalone packages from March 2017**.
On any system updated via monthly Cumulative Updates since then, none of 
these will appear in `Win32_QuickFixEngineering`, even though the fix is 
present. The scanner incorrectly concludes the DC is vulnerable.

### Proof
```powershell
# WMI (what PingCastle sees) — KB4013429 NOT listed despite being patched
Get-WmiObject -Class Win32_QuickFixEngineering | Where-Object HotFixID -eq "KB4013429"
# Returns nothing

# Real build from registry — confirms the system IS protected
$ubr = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").UBR
Write-Host "14393.$ubr"  # Output: 14393.8957  (threshold: 14393.953)

Proposed fix

For Windows Server 2016 (build 14393), instead of searching for a specific
KB in WMI, read the UBR (Update Build Revision) directly from the registry:

HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion → UBR

If UBR >= 953, the DC is protected and the rule should not trigger.

I am not a coder or developer so I cannot help writing a fix, but I will be happy to assist by testing things on my environment.

[JoeDibley]

Thanks for the detailed information. We are looking to make a bunch of improvements in the collection and the resolution of this rule in the next release. Apologies for the issues.

[cerede2000]

Same on MS14-068 rules
The KB3011780 is replaced and my servers are patched with superior KB but Ping Castle 3.5.0.44, privileged mode match the rules...

[JoeDibley]

Correct. We have the fix for this peer reviewed internally. It will be released within the next month or so.

[cerede2000]

Hello, any updates regarding the correction of this issue?

Thank you.

[cerede2000]

Hi,
I just tried Ping Castle version 3.5.1.31 on some false positive cases:

• S-Vuln-MS17_010
• S-Vuln-MS14-068

And this version still doesn't fix the problem.

Although the 2012 R2 domain controllers are properly patched with newer versions that incorporate these fixes, Ping Castle is still reporting both items worth 100 points.

[JoeDibley]

Sorry to hear. I will reopen the bug internally and get someone to investigate this.

[cerede2000]

@JoeDibley I currently have an environment with this issue.

Active Directory 2012 R2, 2012 R2 domain controllers, patched with false positives reported.

If you need any further information or a test, please don't hesitate to ask.

[JoeDibley]

Thanks for the info @cerede2000. I have a 2012 r2 server installing updates to see whats up. Hopefully we can get this figured out for you :)

[jffroment]

I confirm that the bug is still present in the latest release 3.5.1.31

[JoeDibley]

@jffroment Is this also with server 2012 and 2012 r2 specifically?

[jffroment]

@JoeDibley , no, as far as I’m concerned, this happens on a DC with windows server 2016 (build 14393.9140)

[JoeDibley]

We believe we have found the culprit here and made further improvements to this. We will aim to post a release on Thursday or before.