Fix ADCS certihound collection failing with Kerberos auth (GSSAPI ASN1 error)

[0x0Trace]

Description

When using Kerberos authentication (--kerberos or --use-kcache) with --bloodhound --collection All/adcs, the CertiHound ADCS collection fails with ASN1 parsing errors like:

[-] ADCS collection failed: <TagSet object, tags 64:0:21> not in asn1Spec: <LDAPMessage schema object...>

Root cause: Impacket's LDAP recv_raw() method has a bug in its GSSAPI frame reassembly. When Kerberos signing/sealing is active, ADCS queries to the Configuration naming context can return responses spanning multiple GSSAPI frames. The reassembly loop condition (while message_length != len(data) - 4) reads too much data when the initial recv contains more bytes than the first frame's length, causing decrypt() to produce corrupted data that fails ASN1 parsing.

Fix: For Kerberos auth, ADCS collection now creates a fresh ldap3 connection using ADAuthentication.getLDAPConnection() (the same approach BloodHound-CE uses for its own Kerberos LDAP queries). This bypasses impacket's broken GSSAPI wrapping entirely. NTLM/password auth continues to use the existing ImpacketLDAPAdapter which works correctly without GSSAPI.

This PR was created with the assistance of AI (Claude Opus 4.6) for debugging the GSSAPI issue.

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)
• 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

Bug reproduction:

1. Obtain a Kerberos TGT (e.g. via getTGT.py or kinit) and export it as KRB5CCNAME
2. Run: KRB5CCNAME=<ccache> nxc ldap <dc> --use-kcache --bloodhound --collection All --dns-server <dns>
3. Observe the ADCS collection fails with <TagSet object, tags 64:0:21> not in asn1Spec (or similar tag like 192:0:8)
4. The same command with password/hash auth (NTLM) works fine

After fix:

• Kerberos auth uses a fresh ldap3 connection for ADCS collection, no more ASN1 errors
• NTLM auth path unchanged

Test environment:

• Kali Linux 6.16.8, Python 3.13
• Target: Windows Server 2022 Build 20348

Screenshots :

Before :

After :

Checklist:

• 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)

[NeffIsBack]

Very interesting, thanks for the PR!

However, instead of switching to ldap3 (which doesn't support the GSSAPI)) we should fix the bug in impacket (looking at @zblurx :D (he implemented GSSAPI support for impacket so he can probably fix it relatively quickly).

[0x0Trace]

Very interesting, thanks for the PR!

However, instead of switching to ldap3 (which doesn't support the GSSAPI)) we should fix the bug in impacket (looking at @zblurx :D (he implemented GSSAPI support for impacket so he can probably fix it relatively quickly).

Oww xD That would be awesome tbh.

[zblurx]

Hey @0x0Trace , thanks for the PR (and issue) !

I have been trying to reproduce the issue but I can't. Can you give me more details on the setup ? NXC / Impacket version, how did you installed the tools, stuff like that.

Also, I see in your working screenshot that CertiHound collector found 0 certificate template and 0 enterprise CA -> Maybe ldap3 is not working much more than impacket, or maybe your lab is broken ?

[0x0Trace]

Hey @0x0Trace , thanks for the PR (and issue) !

I have been trying to reproduce the issue but I can't. Can you give me more details on the setup ? NXC / Impacket version, how did you installed the tools, stuff like that.

Also, I see in your working screenshot that CertiHound collector found 0 certificate template and 0 enterprise CA -> Maybe ldap3 is not working much more than impacket, or maybe your lab is broken ?

Hey, sorry for the late response been a bit busy.

So regarding the lab setup: the original box where I hit the issue (Ghost machine from HTB, Server 2022 Build 20348) didn't have any certificate templates, which is why the screenshot shows 0 templates and 0 Enterprise CAs. That's expected for that environment ldap3 was working fine, the lab just had no ADCS objects to find.

That said, I went back and tried reproducing the original ASN1 error against Ghost again and couldn't trigger it this time. Tested against a couple of other boxes as well with no luck. So the issue seems to be intermittent or dependent on specific conditions I haven't been able to pin down yet.

No need to continue with this PR if more people report the same issue we can revisit it then.

[NeffIsBack]

Interesting okay, @0x0Trace could you create an issue with your finding(s), so we can track it? Hopefully someone runs into this again and we can figure out what is going on. Either some weird setup or network issues perhaps.