Add SMB module NTLM MIC bypass (CVE‑2025‑54918)

[pol4ir]

Description

This PR introduces a new NetExec module designed to detect systems vulnerable to the NTLM LDAP Authentication Bypass (CVE‑2025‑54918). The module performs reconnaissance via Remote Registry to identify Domain Controllers that may allow NTLM authentication to be reflected to LDAP/LDAPS even when signing and channel binding are enabled.

Since this CVE relies on NTLM reflection, I would recommend grouping all NTLM reflection reconnaissance logic into a single module to avoid creating multiple modules.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Deprecation of feature or functionality
• This change requires a documentation update
• This requires a third party update (such as Impacket, Dploot, lsassy, etc)

Screenshots (if appropriate):

Checklist:

• I have ran Ruff against my changes (via poetry: poetry run python -m ruff check . --preview, use --fix to automatically fix what it can)
• I have added or updated the tests/e2e_commands.txt file if necessary (new modules or features are required to be added to the e2e tests)
• New and existing e2e tests pass locally with my changes
• If reliant on changes of third party dependencies, such as Impacket, dploot, lsassy, etc, I have linked the relevant PRs in those projects
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (PR here: https://github.com/Pennyw0rth/NetExec-Wiki)

[NeffIsBack]

Thanks for the PR!

Please take a look at the discussion in #978 regarding exactly this.

[pol4ir]

Thank you @NeffIsBack

I reviewed the PR and consolidated all CVE checks into a unified logic. Below are the screenshots, which you can also use for the documentation if needed.

[Mauriceter]

Hi, nice improvement! there are a few points that could be improved, in my opinion:

1. I don’t think grouping CVEs should be limited to NTLM reflection vulnerabilities only, so maybe the module name could be more generic.

2. For the output, one line per vulnerability should be sufficient. If this is run against multiple hosts with several vulnerabilities, the output could otherwise become very large.

3. It would be cleaner and easier to maintain to have a single dictionary variable containing the information for all CVEs and to use only one loop. The logic could be simplified along these lines:

cve = {"cve1":{"patches":{...},"message":"vuln to cve1!"},"cve2":{...}}

...
cvestocheck = (CVE if CVE is not None else cve.keys())
for cvetocheck in cvestocheck:
   if vulnerable(...,cve[cvetocheck]["patches"]):
      print(cve[cvetocheck]["message"])

Anyway, that’s just how I see it, probably best to wait for NeffIsBack’s thoughts as well.

[pol4ir]

Thank you for your interest.

1. I think putting all CVEs together in a single codebase would, over time, lead to a hard-to-maintain monolith. Different CVEs often rely on different protocols and workflows, and managing all of them in one block of code would likely become a headache. This is also the approach followed, for example, by Metasploit, where each exploit is handled as a separate module.

2. Yes, I agree with you, and I can easily adjust the output to be on a single line.

That said, I appreciate your opinion, and we can wait to hear NeffIsBack.

[skr19x]

Thanks @pol4ir , I’d been looking for this for a while. I used it in a security assessment and it worked like a charm. I also agree that separating them into different modules would be the better approach

[NeffIsBack]

Pretty much everything @Mauriceter said. This should aim at querying the UBR via winreg once and then display all unpatched vulnerabilities. Then you can just scan a large subnet and every CVE (that actually has an impact on pentesting not just random boring ones) is displayed. E.g. we could also add drop-the-mic (although pretty old) and other interesting vulns.

My thoughts on the bullet points:

1. I think enum_cve would be a good name
2. My idea would be to have a format somewhat like this: CVE-xxxx-xxxx - <alias e.g. ntlm-reflection/drop-the-mic...> - <message>
3. Like this and adding a custom, non-required "signing_msg" where an alternative to the default message is displayed as replacement for the if switch for each vuln. The logic would probably be something like this:

cve = {
    "cve1":{"patches":{...}, "message":"vuln to cve1!", "signing_msg": "SMB-Signing enforced, try cross-protocol relaying to e.g. WinRM"},
    "cve2":{"patches":{...}, "message":"..."},
    "cve3":...
}

...
for cvetocheck in cve.keys():
    if vulnerable(...,cve[cvetocheck]["patches"]):
        if conn.signing and hasattr(cve, signing_msg):
            print(f"{cve} - {alias} - {signing_msg}")
        else:
            print(f"{cve} - {alias} - {message}")

[NeffIsBack]

A few additions/notes:

• We need to deprecate the ntlm_reflection module
• From the previous PR @azoxlpf had the suggestion to add an option for filtering CVEs, so something like -o CVE=CVE-1234-1010,CVE2345-2020... would probably be a good idea
• Include something like "This module only checks the UBR, verify the vulnerability yourself to make sure it actually works" in the option message