Is CVE-2016-0099 (Microsoft Windows Secondary Logon Service Privilege Escalation) being exploited in the wild?

What “exploited in the wild” means for this CVE

CISA’s KEV listing is the practical signal to trust here: it is the government-backed indicator that a flaw has credible evidence of active exploitation, not just theoretical risk. For defenders, that changes the priority from routine patch planning to immediate exposure confirmation, containment, and remediation planning, especially when the affected service is reachable on business-critical Windows systems.

For a Windows privilege escalation issue, the key question is not only whether the vulnerable product exists somewhere in the estate, but whether the vulnerable condition can still be triggered on any host where the Secondary Logon Service is present and usable. A KEV-listed issue should be treated as already in an attacker workflow, which makes time-to-detect and time-to-remediate more important than debating exploitability in principle. See the CISA Known Exploited Vulnerabilities Catalog for the authoritative exploitation status.

For background and cross-checking, the NIST National Vulnerability Database and the CVE Program remain the canonical references for the record itself, while the KEV entry is the operational trigger for response prioritisation.

What defenders should do first on vulnerable Windows systems

Start by identifying every Windows asset that could still be exposed to the Secondary Logon Service weakness, then align patching or vendor mitigation with the current Windows release guidance. On a KEV-listed privilege escalation bug, the defensible assumption is that at least one attacker path already exists in the wild, so the remediation decision should be driven by asset criticality and exposure, not by whether exploitation has been observed in your own environment.

If immediate patching is not possible, reduce blast radius around the vulnerable hosts by tightening administrative access, limiting interactive use of secondary credentials, and monitoring for abnormal privilege changes. A useful benchmark is whether the host can still be used as a stepping stone to a higher-privilege context, because privilege escalation flaws often become the local pivot that turns a low-value foothold into broader domain compromise.

The most useful supporting context is the Zero-Day and Exploited Vulnerabilities Guide, which covers KEV triage, emergency mitigation, and post-patch hunting. For teams running formal vulnerability programs, the Vulnerability Management Guide is the better fit for prioritisation, SLAs, exceptions, and verification.

Why privilege escalation flaws matter after initial access

Privilege escalation is dangerous because it converts limited access into control over the local machine, and that often creates a path to credential access, persistence, lateral movement, or defensive evasion. The Windows Secondary Logon Service flaw is not just a patching issue, it is an access-amplification issue, which means a single compromised account, service, or foothold can become a much larger incident if the vulnerable host is also weakly monitored or overprivileged.

That is why attackers value these bugs even when they do not provide remote entry by themselves. Once exploitation is possible on an internal system, the next step is often to harvest further secrets, launch higher-privilege tooling, or move toward systems that were assumed to be protected by normal user boundaries. The relevant technique family is well captured in the MITRE ATT&CK Enterprise Matrix, especially privilege escalation and credential access patterns.

Where the affected host is part of a larger Windows estate, the practical control question is whether local privilege boundaries are actually limiting what an attacker can do, or merely delaying escalation for a few minutes. That is the point at which access control, service hardening, and monitoring become incident response concerns rather than simple patch hygiene.

Risk and Threat Considerations

A KEV-listed privilege escalation flaw creates immediate exposure because it can be chained from a foothold into broader system control, especially if the vulnerable Windows host carries cached credentials, admin tooling, or remote management reach. In ransomware cases, that kind of local escalation is often what turns initial access into meaningful operational impact.

Failure mechanism: the Secondary Logon Service mishandles request handles in memory, allowing a local attacker to trigger privilege escalation and obtain higher rights than intended.

Impact: a successful exploit can enable system takeover, credential access, persistence, or lateral movement, and it may materially shorten the time between initial compromise and enterprise-wide impact.

Practitioner Guidance

What to prioritise: Treat KEV-listed privilege escalation bugs as exposure management problems, not ordinary backlog items. Confirm which Windows systems are still in scope, whether the vulnerable service is enabled, and whether those hosts have any path to sensitive credentials or administrative tooling.

What to verify: After remediation, verify that the patch or mitigation is actually effective on the host build you run, and then validate that no unusual privilege transitions, suspicious service activity, or post-exploitation artefacts remain on the system.

Practitioner takeaway: For a KEV-listed local privilege escalation, the right question is not “is it being exploited somewhere,” but “how much control would an attacker gain if they reached this host today?”

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2016-0099 (Microsoft Windows Secondary Logon Service Privilege Escalation)?
• CVE-2016-0099 (Microsoft Windows Secondary Logon Service Privilege Escalation)
• Is CVE-2023-28229 (Microsoft Windows CNG Key Isolation Service Privilege Escalation) being exploited in the wild?
• Is CVE-2022-41125 (Microsoft Windows CNG Key Isolation Service Privilege Escalation) being exploited in the wild?