Added the certifried module

[E1A]

Description

This PR adds a LDAP module to check whether the DC and CA show signs of being vulnerable to Certifried (CVE-2022-26923)

It does the following:

• Enumerates CAs and published templates with Certipy
• Requests a client-auth certificate from the CA
• Checks whether the issued certificate contains the post-may-2022 SID security extension
• If the certificate is SID-less, attempts an LDAPS Schannel bind with that certificate against the DC

The module reports three outcomes:

• CA-side hardening present: issued cert includes the SID extension
• Possible vulnerable to Certifried, SID-less user cert accepted over Schannel
• SID-less cert was rejected over Schannel

For machine accounts, the module checks the LDAP object type, prefers the Machine template and fails if the account has no dNSHostName

What this module proves (not 100% guarantee if the vuln is present):

• Whether the CA issues a SID-less client-auth certificate
• Whether the DC accepts that SID-less certificate over LDAPS Schannel

No new third party dependency update is required

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)

Setup guide for the review

Tested locally with Python 3.11.2 on Debian WSL
Reviewer requirements:

• An AD environment with a CA
• LDAPS enabled on the DC if the Schannel part is tested

Module options:

• CA: restrict checks to a specific CA name
• PASSIVE_TEMPLATE: force a specific template for the CA/DC probe
• TIMEOUT: timeout in seconds for Certipy operations

Review command:

• netexec ldap $dc_ip -u $user -p $password -M certifried

Validation performed:

Vulnerable environment (ludus):
Domain user

• User template issued a SID-less cert
• Schannel accepted the certificate
• The module reported that the system could be vulnerable

Machine account without a dNSHostName (default when its created using the add-computer module):

• The module preferred the Machine template
• The module failed cleanly with Machine cert probe failed, machine account has no dNSHostName

Machine account with a dNSHostName:

• Machine template issued a SID-less cert
• Schannel accepted the certificate
• The module reported that the system could be vulnerable

Patched environment (ludus):
Domain user

• User template issued a cert with the SID extension present
• Schannel was skipped
• The module reported that CA-side hardening is present

Machine account without a dNSHostName (default when its created using the add-computer module):

• The module preferred the Machine template
• The module failed cleanly with Machine cert probe failed, machine account has no dNSHostName

Machine account with a dNSHostName:

• Machine template issued a cert with the SID extension present
• Schannel was skipped
• The module reported that the CA is patched

Tryhackme CVE-2022-26923 room (https://tryhackme.com/room/cve202226923)
Domain user

• User template issued a SID-less cert
• Schannel accepted the certificate
• The module reported that the system could be vulnerable

lmk if I need to provide my ludus config ranges files :D

Screenshots (if appropriate):

Unpatched

Domain user

Machine accounts

Patched

Domain user

Machine accounts

Checklist:

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

• 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, definitely looks cool!

[Dfte]

Shouldn't we import that into the enum_cve now ?

[NeffIsBack]

Hmm we could/should probably add the cve to enum_cve as well, but this probes the vuln "actively" as fas as i can tell, so probably not something that should also be executed along side the UBR querying stuff.

[E1A]

I can open a PR for this in enum_cve but it would not be a fully reliable check. For Certifried patching the DC does not tell the whole story because the CA side and existing cert state matter too. Better to keep it a seperate module imo

[azoxlpf]

After looking into how the vuln and patches work, I think integrating it into enum_cve would actually be sufficient. If both the DC and CA have KB5014754 applied, the attack chain is broken, even in compatibility mode (StrongCertificateBindingEnforcement = 1), a SID mismatch is still blocked. So imo checking the UBR on both the DC and the CA gives a reliable signal