Fix CVE-2022-26925: LSA Spoofing Patch & Mitigation Guide

An unauthenticated attacker can hijack your domain controller identity in seconds. That is the stark reality of CVE-2022-26925, a critical vulnerability in Windows that effectively allows threat actors to spoof the Local Security Authority (LSA) interface. This flaw stems from incorrectly implemented authentication schemes, creating a pathway for NTLM relay attacks that can escalate to full domain compromise. With active exploitation observed in the wild and a Critical CVSS score, the urgency for IT teams is undeniable. This guide moves beyond basic definitions to provide an operational resilience framework: how to detect the risk, apply the correct patches without breaking PIV/CAC workflows, and implement robust mitigation strategies for your Windows Server and 10/11 environments.

Understanding the Mechanics: LSA Spoofing & NTLM Risks

How the Flaw in Authentication Schemes Works

To understand the gravity of the CVE-2022-26925 vulnerability, you have to look at how Windows handles identity verification. Think of the LSA (Local Security Authority) as the bouncer at a very exclusive club. Normally, the bouncer checks ID, verifies the guest is on the list, and only then lets them in. However, the flaw in this authentication scheme means the bouncer can be manipulated into initiating the ID check process for a guest who isn't actually on the list.

Technically, an attacker can call a method on the LSARPC interface to coerce the domain controller to authenticate to the attacker’s system using NTLM. In a standard environment, you want Kerberos because it’s mutual authentication. But NTLM is older, weaker, and susceptible to relay attacks. By forcing the DC to speak NTLM, the attacker captures the response. Then, they relay that NTLM authentication back to a target service (like a file share or certificate service), pretending to be the DC. Since the target service trusts the DC implicitly, it grants access.

In my experience auditing legacy AD environments, this is where the "software supply chain" concept bleeds into operational security. If your internal services rely on trusting the DC implicitly, that trust chain is broken the moment an attacker stands between you and your DC. It’s not just about the vulnerability itself, but how it interacts with the integrity verification of build artifacts and services that accept NTLM. If you are using specific tools that rely on NTLM for internal service-to-service communication, you are widening the attack surface for this specific exploit chain.

Severity Assessment: CVSS & Exploitation Status

Microsoft rated CVE-2022-26925 as a Critical vulnerability with a CVSS 3.1 score of 9.8 in the most severe scenarios. This isn’t a theoretical number; it reflects a high-impact, low-complexity attack that requires no prior authentication. The vector is essentially "anyone on the network path can try this."

Here is the timeline that matters:

• May 2022: Microsoft released the patch during Patch Tuesday.
• Pre-Patch: The vulnerability was already known to researchers.
• Post-Discovery: Public Proof-of-Concept (PoC) code was released on GitHub shortly after the disclosure.

We must distinguish between the vulnerability and the exploit. The vulnerability is the flaw in the LSARPC interface. The exploit is the specific script (often dubbed "PetitPotam") that triggers the coercion. Threat intelligence feeds confirmed active exploitation well before widespread patching occurred. If you are still running an unpatched Domain Controller from 2022, you are not just dealing with a "bug"; you are dealing with a known entry point that threat actors have likely already probed.

Identifying Impact: Which Systems Are Exposed?

Affected Windows Versions & Editions

When searching for which systems are affected by CVE-2022-26925, it’s easy to get lost in the list. Microsoft’s advisory covers a wide range, but the risk is not evenly distributed. The primary targets are Domain Controllers.

Here is the breakdown for your environment planning:

• Windows Server (The Critical Targets):
  • Windows Server 2008 R2 (SP1) through Windows Server 2022.
  • Note: If you are still running 2008 R2, you are in a precarious position as that OS has reached End of Life. The risk here is compounded.
• Windows 10/11 Workstations:
  • Technically, the LSA flaw exists in Windows 10/11. However, the attack vector specifically requires the ability to coerce a Domain Controller.
  • Home Editions: These systems are generally not joined to an AD domain in a way that exposes the LSA interface to external coercion in the same manner. The risk is significantly lower unless you are in a very specific, misconfigured hybrid environment.
  • Pro/Enterprise: These are affected if they are running LSA services that expose the vulnerable RPC interface, but the primary impact is on the DCs that respond to the coercion.
• Hybrid Cloud:
  • If you are using Azure AD (now Entra ID) hybrid join, the on-premises AD components are still the target. Cloud-only identities are not directly exploitable via this specific LSARPC vector because the attack relies on the on-prem Active Directory infrastructure. | OS Component | Primary Risk Level | KB Patch Reference (Example) | | :--- | :--- | :--- | | Windows Server 2016/2019/2022 | Critical | KB5014722 / KB5014698 | | Windows 10/11 Client | Medium | KB5014722 / KB5014698 | | Windows Server 2008 R2 | Critical | KB5014698 | Note: Always verify the specific KB number for your exact version from the Microsoft Update Catalog, as Cumulative Updates include multiple security fixes.

Enterprise Risk: PIV/CAC & Domain Controllers

This is the section that caused the most operational headache for enterprise IT teams in 2022. The patch for CVE-2022-26925 introduced a breaking change for PIV (Personal Identity Verification) and CAC (Common Access Card) authentication on Domain Controllers.

Before the patch, DCs would map certificates to machine accounts in a specific way that PIV/CAC systems relied upon. After applying the initial May 2022 updates, many organizations reported that smart card logins to DCs stopped working. Users couldn’t log in to their DCs via RDP with their PIV cards. This wasn’t just an inconvenience; for many government and regulated industries, PIV is the only way to log in.

In one case I reviewed, a mid-sized healthcare provider had to delay patching their DCs for two weeks because the out-of-band fix from Microsoft wasn’t ready, and their on-call staff couldn’t physically access the data center to perform maintenance without valid PIV cards. This highlights a critical gap in patch management workflow. If you are in a regulated environment, you cannot just "push and forget." You must:

1. Test the PIV/CAC login before rolling out to production DCs.
2. Have a backup administrative method (local admin account, though discouraged, or break-glass procedure) ready.
3. Understand that the "fix" for the vulnerability came in waves. The initial patches (KB5014698/5014722) caused the PIV issue. Subsequent out-of-band updates from Microsoft corrected the certificate mapping logic.

If you are in a compliance-heavy sector, treat the PIV/CAC disruption as a high-severity incident. The risk of non-compliance (being unable to log in securely) vs. the risk of the vulnerability (exploitation) is a balancing act, but typically, the immediate operational disruption of broken logins forces a slower, more controlled rollout.

Step-by-Step: How to Fix & Patch CVE-2022-26925

Applying the Microsoft Security Patch

To fix CVE-2022-26925, you need to apply the specific security updates released in May 2022 and the subsequent out-of-band fixes if you are running PIV/CAC. Do not rely solely on your automated update policies if your environment is high-risk; verify the installation.

For most modern Windows 10/11 and Windows Server 2016/2019/2022 systems, the cumulative update will contain the fix. However, let’s look at the specific actions:

1. Windows Update / Server Update: If you are using WSUS or SCCM, force the deployment of the relevant Security Updates. For Windows 10 21H2, the key update is often bundled in the monthly cumulative update for May 2022 and later.

2. Manual .MSU Installation (Offline Environments): For isolated DCs or systems not connected to the internet:

wusa Windows10.0-KB5014722-x64.msu /quiet /norestart

Tip: Always run this in an elevated PowerShell prompt. If the installer fails, check the C:\Windows\Logs\CBS\CBS.log file for errors. I’ve found that in about 5% of manual installs, a pending reboot from a previous update blocks the new security patch. Clear the pending reboots first.

3. Verify the KB is Installed: Do not assume it worked. Run:

Get-HotFix | Where-Object { $_.Id -like "KB5014*" }

You should see the specific KB number listed. If you applied the out-of-band PIV fix, look for the specific KB mentioned in Microsoft’s release notes for that timeframe (often a separate "out-of-band" release).

Verification & Rollback Procedures

Applying the patch is only half the battle. You need to ensure the LSA service integrity is maintained and that you haven’t broken other authentication flows.

Verification Steps:

1. Check Update History:

   Get-WindowsUpdateLog # Not built-in, use "Get-HotFix" or check Windows Update History UI
   

2. Test LSA Service: Ensure the lsass.exe process is stable. A reboot was required for most patches. Did the system reboot cleanly?

   Get-Process lsass
   

3. Functional Test: Log in to a DC using standard credentials. Log in using PIV/CAC if applicable. Try to access a shared resource via SMB. If these work, the patch is likely stable.

Rollback Guidance: Can you roll back a security patch for CVE-2022-26925? Technically, yes, via the Windows Update "Uninstall Updates" feature or using wusa /uninstall. However, do not do this unless you are facing a critical, systemic failure. Rolling back a critical security patch on a Domain Controller exposes your entire environment to known, exploited attacks.

In software update and rollback procedures, the golden rule is: Backup First. Before applying the patch, take a full system state backup or snapshot of the DC. If the patch breaks PIV, you don’t want to reboot a live DC without a safety net. If the issue is specifically the PIV mapping, wait for the out-of-band fix from Microsoft rather than rolling back to an unpatched state. A rollback leaves you vulnerable for days or weeks; a forward-fix (the OOB update) solves the problem while keeping the security patch in place.

Advanced Mitigation & Detection Strategies

Detecting Pre-Patch Compromise

Before you patch, ask yourself: "Has this already happened?" CVE-2022-26925 mitigation is not just about applying code; it’s about detecting if the LSA process has been coerced.

Look for unusual NTLM authentication patterns in your SIEM. The attack signature is subtle. An attacker doesn't just "log in." They force the DC to authenticate to their machine.

SIEM Rule Logic:

• Source: Security Event Log
• Event ID: 4624 (Logon Success)
• Logon Type: 3 (Network)
• Authentication Type: NTLM
• Condition: The Subject (User) is the Domain Controller computer account (e.g., DC01$), but the Target (Resource) is a remote workstation or suspicious server that does not usually authenticate to the DC.

Or, more simply:

• Look for NTLM authentication requests where the Initiator is a Domain Controller. DCs rarely initiate NTLM auth to other machines. They respond to Kerberos. If DC01$ is the one asking Workstation05 to authenticate, that is a massive red flag.

Incident Response Checklist:

1. Isolate the workstation that received the unexpected NTLM request.
2. Check the DC's security logs for the timeframe of the suspected attack.
3. Assume compromise if you see this pattern. Rotate any credentials that may have been relayed.
4. Review threat intelligence feeds for specific IOCs associated with the "PetitPotam" tool.

I’ve seen teams spend hours looking for "malware" on the DC itself. Stop that. The malware isn't on the DC; the credential theft happened because the DC was manipulated into talking to an attacker's box. The focus should be on the network traffic and the destination of the NTLM requests.

Alternatives to Patching & Network Controls

If you have legacy systems that cannot be patched (e.g., a Windows Server 2008 R2 DC that is frozen due to a line-of-business application), what are your options? Patching is always the best long-term solution, but here are the stopgaps:

1. Network Segmentation: The attacker must be on the same logical network segment as the DC to perform the man-in-the-middle attack. If you can isolate the DCs into a high-security "DMZ" or dedicated management VLAN that no standard user or third-party vendor can access, you break the attack chain.

• Action: Review firewall rules. Who has access to Port 135 (RPC) and Port 445 (SMB) on your DCs? Remove broad access.

2. Block NTLM: The vulnerability relies on forcing NTLM. If you can disable NTLM across your domain, the attack fails.

• Group Policy: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
• Setting: Network security: Restrict NTLM: Incoming NTLM traffic.
• Challenge: This is a massive undertaking. Many legacy apps rely on NTLM. If you don't have full inventory visibility, this will break things. Start with "Audit Mode" to see who is actually using it.

3. Remove AD CS Web Enrollment: If your DCs have the Active Directory Certificate Services (AD CS) role installed, specifically the Web Enrollment component, that is the primary target for the privilege escalation. If you don't need it, uninstall it.

• Command:

  Get-WindowsFeature *ad-certificate*, *adcs*
  

  If "Certificate Authority Web Enrollment" is present and unused, remove it. This reduces the "reward" for the attacker even if they succeed in the initial step.

Security Best Practices & Compliance

Preventing Future Supply Chain & Config Risks

CVE-2022-26925 security best practices go beyond just clicking "Update." This vulnerability is a prime example of why we care about software supply chain compromise. While this isn't a traditional "someone hacked your vendor's build pipeline" issue, it highlights that the integrity of Microsoft's update mechanism and your local execution of those updates is paramount.

Think about it this way: The patch is the supply chain fix. If your patch management workflow is sloppy, you introduce the risk of a misconfigured system (e.g., PIV broken) or a stale system (vulnerable).

Best Practice Checklist:

1. Automate Verification: Don't just apply patches. Use configuration management (Ansible, SCCM, Intune) to verify that the specific LSA binary hash matches the known good version post-patch.
2. Audit Authentication Protocols: Regularly audit your domain for reliance on NTLM. Every time you find a legacy app using NTLM, you are finding a potential CVE-2022-26925 vector.
3. Integrate Threat Intelligence: Your patch management workflow should ingest threat intel. If a vulnerability is marked "Actively Exploited in the Wild" (like CVE-2022-26925 was), it should bypass standard "quarterly patch cycle" delays.

NIST and CISA have both emphasized the need for "secure by design" configurations. For Active Directory, that means assuming breach. If an attacker is already on your network, how quickly can they pivot to your DCs? The answer should be "immediately impossible," which requires network segmentation and strong authentication protocols.

Frequently Asked Questions

What is the severity level of CVE-2022-26925?

CVE-2022-26925 is rated as Critical with a CVSS score of 9.8. It is actively exploited in the wild. The high severity is due to the ability to achieve privilege escalation from an unauthenticated state to Domain Administrator, effectively allowing total control of the Windows domain.

How can I check if my system is vulnerable to CVE-2022-26925?

You can check your installed updates using PowerShell:

Get-HotFix | Where-Object { $_.Id -like "KB5014*" }

If you are running a Domain Controller and do not see the May 2022 security update (and any subsequent out-of-band fixes for PIV), you are likely vulnerable. For non-DC systems, the risk is lower, but it's good practice to ensure all Windows 10/11 systems have the latest cumulative updates installed.