Support for CVE-2025-54918 (NTLM Partial MIC Removal) Detection

[TheGr3atJosh]

Please Describe The Problem To Be Solved
Currently, NetExec has modules/checks for NTLM reflection (like CVE-2025-33073), but these do not account for the logic flaw identified in CVE-2025-54918.

While CVE-2025-33073 focuses on bypassing SMB loopback restrictions via DNS/hostname manipulation, CVE-2025-54918 is a logic error in the NTLM stack's validation routine. This flaw allows an attacker to perform a "Partial MIC Removal" attack. By stripping the Message Integrity Code (MIC) and specific flags from the NTLM AUTHENTICATE_MESSAGE, an attacker can successfully relay authentication to services that normally enforce signing (like LDAP/S or SMB with signing required).

The problem is that a host might be patched against CVE-2025-33073 but still remain vulnerable to CVE-2025-54918. Existing NTLM relay or coercion checks in NetExec do not currently attempt this specific MIC-stripping bypass, leading to potential false negatives during security assessments of Windows Server 2025 and 24H2 environments.

In-scope:

• A check module to determine if a target's NTLM stack accepts authentication attempts where the MIC has been removed/tampered with.

Out-of-scope:

• General NTLM relaying or exploitation (already covered by existing tools).

(Optional): Suggest A Solution

Technical Implementation:
The solution requires a module that performs a modified NTLM handshake.

1. Bypass: During the NTLMv2 authentication flow, the module must modify the AUTHENTICATE_MESSAGE. It needs to:
   • Remove the msAvFlags (specifically the bit indicating a MIC is present).
   • Remove the MIC field itself from the end of the NTLM packet.
2. Check: The module should attempt this "stripped" authentication against the target. If the target accepts the authentication (instead of returning STATUS_INVALID_PARAMETER or SEC_E_LSA_CONTEXT_NOT_FOUND), the host is vulnerable.
3. Library Dependency: This may require using a modified version of the impacket NTLM stack (similar to the logic used in the impacket-partial-mic PoCs) or manually crafting the NTLM structure within the module.

Tradeoffs and Design Decisions:

• Protocol specific: While the vulnerability is in the NTLM stack, the most critical impact is relaying to LDAP. The module should ideally be able to test both SMB and LDAP endpoints.

Caveats and Considerations:

• CVE-2025-54918 is specifically prominent on newer Windows builds (Server 2025 / 24H2). The module should ideally fingerprint the OS version to provide context to the user.
• Since this involves altering authentication headers, it could trigger EDR alerts for "NTLM Tampering" or "Suspicious NTLM Authentication."

[NeffIsBack]

Thanks for the feature request!

Sounds like a good idea👍 A "passive" Check via the UBR will be implemented in #1086.

[NeffIsBack]

Actually we could add a module that actively checks for all kinds of NTLM vulnerabilities and NTLMv1. One existing module that does this is the remove-mic module which could act as a POC.

[TheGr3atJosh]

That sound's even better.

[NeffIsBack]

Remark on the NTLMv1, probably not possible/not really suitable because for that we need an incoming connection which require an SMB Server and coercion. Probably something better suited for ntlmrelay or the smb server in impacket