CVE-2016-0099: Microsoft Windows Secondary Logon Service Privilege Escalation Vulnerability

CVE-2016-0099 is a privilege escalation vulnerability in Microsoft Windows affecting the Secondary Logon Service. When that service mishandles request handles in memory, a local attacker can elevate to administrator-level rights and run arbitrary code. It matters because successful exploitation turns limited access into full control of the host, and this issue has been used in ransomware campaigns. Confirm exact product scope and fixed builds against the Microsoft advisory.

How it works

The weakness falls under CWE-264 (permissions, privileges, and access controls). The Secondary Logon Service is responsible for running processes under alternate credentials. According to the CISA summary, it fails to properly manage request handles in memory. An attacker who already has a foothold on the system can abuse that mismanagement to obtain higher privileges and execute code as an administrator. Public detail on exact memory layout or trigger sequences is limited; treat any exploit descriptions outside the vendor advisory as unverified. The practical outcome is local elevation of privilege, which is commonly chained after initial access to deploy further payloads, including ransomware.

Am I affected? How to find it in your systems

The vulnerability affects Microsoft Windows systems that include the Secondary Logon Service (the service that supports “Run as” / secondary logon functionality). It is present on typical desktop and server installations unless the service has been deliberately disabled.

• Inventory Windows hosts via your CMDB, endpoint management console, or scripts that query OS version and installed updates.
• Confirm whether the Secondary Logon service (seclogon) is present and running; check service state with standard administrative tools.
• Compare installed security updates against the Microsoft bulletin for CVE-2016-0099; do not rely on version strings alone—verify the specific KBs listed in the vendor advisory.
• Review authentication and process-creation logs for unusual use of secondary logon, unexpected elevation to SYSTEM or Administrator, or processes spawned shortly after low-privilege activity. EDR telemetry showing handle abuse or anomalous token manipulation around seclogon can be an indicator, but absence of such signals does not prove safety.

If you cannot map a host to a patched build listed by Microsoft, treat it as potentially vulnerable until confirmed.

How to remediate

Patch first. Apply the security updates Microsoft released for this vulnerability, following the vendor instructions referenced by CISA (“Apply updates per vendor instructions”). Use your standard patch pipeline—WSUS, ConfigMgr, Intune, or equivalent—to deploy the correct packages for each Windows edition and architecture.

• Prioritize internet-facing jump hosts, RDP servers, shared workstations, and any system where untrusted users can obtain a local session.
• After patching, verify the update is installed and reboot if required by the package.
• As hardening for this class of issue, enforce least privilege so that routine users and service accounts cannot reach interactive or secondary-logon paths unnecessarily; restrict who may use “Run as” and similar features via group policy where operationally feasible.
• Keep EDR and tamper protection enabled so post-exploitation activity is harder to hide.

If you can't patch immediately

Compensating controls reduce but do not eliminate risk:

• Segment and restrict local logon: limit which accounts can log on interactively or via RDP to high-value hosts; place vulnerable systems in tighter network zones.
• Disable or restrict the Secondary Logon service only if your environment does not require “Run as” functionality; test thoroughly before enforcing, because legitimate admin workflows may break.
• Apply application control (e.g., allow-listing) so that even an elevated context cannot freely launch untrusted binaries.
• Increase monitoring on seclogon-related process creation, token duplication, and sudden privilege changes; alert on anomalies and retain logs for incident response.
• Virtual patching via host firewall or EDR behavioral rules can block known exploitation patterns if your vendor supplies them—validate any signature against the Microsoft advisory rather than third-party claims.

Schedule the official update as soon as possible; compensating controls are temporary.

If your data may have been exposed

Privilege-escalation flaws that are actively exploited, including those used by ransomware operators, frequently precede data theft or encryption. If you have evidence of exploitation or ransomware activity on affected hosts, follow your incident-response plan: isolate systems, preserve volatile evidence, reset credentials for privileged accounts, and assess what data the elevated attacker could reach. You can also run a free exposure scan of your email addresses against known breach datasets to see whether associated credentials or personal data already appear in public dumps, then force password changes and enable multi-factor authentication where needed.