Add certighost module

[azoxlpf]

Description

Adds the certighost LDAP module, which exploits CVE-2026-54121 (AD CS cdc-chase enrollment redirection) to obtain a Domain Controller certificate.

Ported from the public PoC:

• https://github.com/aniqfakhrul/CVE-2026-54121

The module starts rogue SMB/LDAP listeners, relays NTLM to the real DC via Netlogon, and saves the issued .pfx.

AI disclosure: Claude Opus 4.6 was used to structure the PoC port into a NetExec module.

Type of change

Insert an "x" inside the brackets for relevant items (do not delete options)

• 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)
• This PR was created with the assistance of AI (list what type of assistance, tool(s)/model(s) in the description)

Setup guide for the review

Check whether the ADCS server is vulnerable :

run nxc ldap $DC_IP -u "$USER" -p "$PASSWORD" -M certighost -o L="$ATTACKER_IP"

Screenshots (if appropriate):

With user :

With computer account :

Specific target :

Checklist:

Insert an "x" inside the brackets for completed and relevant items (do not delete options)

• I have ran Ruff against my changes (poetry: poetry run ruff check ., 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)
• 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 linked relevant sources that describes the added technique (blog posts, documentation, etc)
• I have performed a self-review of my own code (not an AI review)
• 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)

[azoxlpf]

@NeffIsBack Have fun 😄

[NeffIsBack]

@NeffIsBack Have fun 😄

Me:

• Sees Certighost module
• Me happy
• Sees +1,061
• Sees import subprocess
• Me frightened

[Dfte]

Jesus 😭
If we ever have to implement listerners back to NXC, I'd rather have it in the core so that we can, for example, dump LSASS directly to the attacker's computer without the dump touching the FS xD

[NeffIsBack]

Jesus 😭 If we ever have to implement listerners back to NXC, I'd rather have it in the core so that we can, for example, dump LSASS directly to the attacker's computer without the dump touching the FS xD

Actually we had just that, including functions for fileless command execution, directly connecting back to the attacker machine. However we removed it a couple of months ago because it never has been used. If we would need something like that we can just revert the commit.

[Dfte]

Jesus 😭 If we ever have to implement listerners back to NXC, I'd rather have it in the core so that we can, for example, dump LSASS directly to the attacker's computer without the dump touching the FS xD

Actually we had just that, including functions for fileless command execution, directly connecting back to the attacker machine. However we removed it a couple of months ago because it never has been used. If we would need something like that we can just revert the commit.

Yeah I know, we can revert. That opens new issues tho, should we run nxc as root again ? Or set the capability directly when installing the tool ? Adding it back re-opens few questions :/

[NeffIsBack]

Naa never run nxc as root. If we need that we just try to start the server and if it crashes we alert the user.

[Dfte]

So I have looked at the module with Azox, both the SMB and LDAP server are custom implementations. So we don't have to integrate back the impacket.smbserver/ldapserver. We still have to check for the capability which is what Azox does. Sooooo should be okay ;D

[mpgn]

wtf

[Dfte]

What's the issue ? The capability check ? Nxc will have to be able to listen on 445

[mpgn]

no subprocess allowed

[NeffIsBack]

no subprocess allowed

This haha. @azoxlpf please remove it. Just try to launch the server and catch it if we don't have privs. At the end of the day ntlmrelay does the same thing

[azoxlpf]

Done

[Marshall-Hallenbeck]

There's a lot of functions and classes in here, are any useful outside of this module, or are any redundant? I know you disclosed using AI in the creation of it, but this seems fully AI generated. Did you check if any of these functions already exist?

[azoxlpf]

There's a lot of functions and classes in here, are any useful outside of this module, or are any redundant? I know you disclosed using AI in the creation of it, but this seems fully AI generated. Did you check if any of these functions already exist?

Nooo, AI was only used to port the original poc into an nxc module, so most of the code comes from there. The number of classes is because these functions don’t exist in nxc/impacket (rogue LDAP server, fake LSA, Netlogon oracle, ICertRequest), so they had to be implemented from scratch

[azoxlpf]

@Marshall-Hallenbeck After digging through the impacket code, you were right, a couple of classes from the original poc already exist in impacket, so I swapped them out and shaved off a few lines ahaha

[jsdhasfedssad]

Hi,

Thank you for this module. I have ADCS installed on a DC (10.0.0.200) in my lab. In my testing I observe the below:

NXC PR 1332 cloned yesterday claims that my ADCS instance is not vulnerable to Certighost.

Attempting to abuse Certighost using NXC PR 1332 fails due to "cdc-chase requires a CA on a member server".

Using the original POC abusing Certighost works...

How come NXC claims that my ADCS instance is not vulnerable when it seems to be? How come NXC claims that ADCS instances installed on DCs cannot be abused when it does not seem to be an issue?

Thanks!

[azoxlpf]

Regarding the CA on the DC, a PR has been merged on Impacket and on the original poc enabling exploitation in that case, I've just pushed the fix to the module, thanks for your feedback!

However, regarding your screenshot showing that enum_cve reports CertiGhost as not vulnerable, that seems legitimate to me, since the poc you're running doesn't appear to be CertiGhost, test with the original poc (https://github.com/aniqfakhrul/CVE-2026-54121) as well as the new version of my module