CVE-2021-36942 is a local security authority (LSA) spoofing vulnerability in Microsoft Windows. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2021, which means attackers have used it in real attacks. Organisations running the affected product should apply the vendor fix or mitigation as a priority.
What this vulnerability means in practice
LSA spoofing on Windows matters because the Local Security Authority sits close to authentication, logon processing, and sensitive security decisions. When that trust boundary is abused, an attacker can impersonate trusted system behaviour and move from a vulnerability into broader identity compromise.
For organisations, the practical concern is not just the CVE label itself, but whether Windows endpoints, servers, or higher-value administrative systems are exposed to a vulnerability that has already been used in real attacks. The CISA KEV listing is a strong signal to prioritise exposure review and remediation.
Why LSA spoofing is dangerous
LSA spoofing is dangerous because it can undermine the integrity of authentication-related operations on a Windows host. If an attacker can deceive a security subsystem that users and services rely on, they may obtain or manipulate access in ways that are hard to distinguish from legitimate activity.
This kind of weakness is especially serious on systems that hold privileged sessions, domain trust relationships, or credentials used for administration. A successful spoofing path can become a stepping stone to credential theft, lateral movement, or persistence.
For more background on Windows hardening around this attack surface, see Windows Endpoint Hardening Guide and the related Endpoint Hardening Checklist.
How organisations assess exposure
Exposure review starts with an accurate asset inventory, then checks where the vulnerable Windows product is deployed, whether those systems are internet-facing, and whether they support administrative, identity, or endpoint management functions. The question is not only “is it installed?” but “where would compromise matter most?”
Vendor advisory guidance should be used for version-specific remediation details, while CISA KEV should be used to confirm that the issue is being actively exploited. If the affected systems cannot be patched immediately, administrators should review compensating controls, reduce exposure, and treat the affected hosts as priority risk items.
Good verification also includes hunting for related configuration weaknesses and ensuring security baselines are present. Vulnerability Management Guide is useful here because it ties asset scope, KEV prioritisation, and remediation verification together.
Detection and recovery after patching
Once exploitation is suspected or confirmed, defenders should look for signs of unusual logon behaviour, process activity, service creation, and attempts to clear or suppress Windows logs. Post-patch review matters because fixing the CVE does not prove the host was not already compromised.
Security teams should also review whether privileged accounts, service accounts, tokens, or cached credentials on the affected system could have been exposed during the incident window. If an attacker reached a trusted Windows security boundary, identity recovery may matter as much as system repair.
Windows Event Log Guide is a useful reference for the event types that support this review, especially around logon events, account changes, and log tampering.
Risk and Threat Considerations
This vulnerability creates material risk because it targets a core Windows trust path that can be used to support credential abuse, persistence, and lateral movement after initial access. In environments with privileged Windows sessions, the blast radius can extend well beyond the original host.
Failure mechanism: An attacker exploits spoofing behaviour to impersonate trusted LSA activity, weakening the integrity of authentication-related decisions and enabling follow-on compromise of accounts or sessions.
Impact: The result can include credential exposure, unauthorized access, privileged movement across the environment, and the need for broader incident response beyond simple patching.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | CVE-2021-36942 requires timely vulnerability remediation on exposed Windows hosts |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-exploit review depends on log analysis for suspicious LSA-related activity | |
| IA-2 — Identification and Authentication (Organizational Users) | LSA spoofing threatens Windows authentication pathways for organizational users | |
| Recommendation — Prioritise SI-2 remediation for affected Windows systems and verify the fix on every exposed asset. Use AU-6 to review Windows event data for signs of spoofing, privilege misuse, and log tampering. Apply IA-2 protections to harden user authentication paths that the exploit can abuse. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | The issue is most damaging where privileged Windows access is broadly available |
| Recommendation — Reduce privileged Windows access paths so an exploited host cannot easily escalate or pivot. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Endpoint hardening is a direct mitigation for Windows LSA exposure |
| Recommendation — Apply secure configuration baselines to reduce Windows attack surface and LSA-related risk. | ||
| MITRE ATT&CK | T1556 — Modify Authentication Process | LSA spoofing aligns with adversary abuse of authentication processes |
| Recommendation — Map suspicious Windows authentication manipulation to T1556 and hunt for related compromise activity. | ||
Practitioner Guidance
Why practitioners should care: Treat this as a high-priority Windows trust-boundary issue, not a routine software defect. KEV-listed exploitation means remediation should be driven by exposure and business criticality, not by ordinary patch queues.
What to watch for: Focus on systems that host administrative activity, store reusable credentials, or provide access to sensitive Windows infrastructure. If the host participates in identity-heavy workflows, assume compromise has a higher downstream cost.
Practitioner takeaway: Prioritise affected assets first, then verify whether the host was used for authentication or administration before closing the case.