Fix Kerberoasting against AES-only

[termanix]

Description

This PR adds an automatic fallback: on KDC_ERR_ETYPE_NOSUPP from getKerberosTGS.

On real life test, when kerberoasting over LDAP, nxc forces an RC4. Against AES-only service accounts / RC4-disabled domains the KDC rejects this with KDC_ERR_ETYPE_NOSUPP and no hash is returned — mirroring Impacket GetUserSPNs.py, which only works there with -no-rc4 flag.

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

Against real life test (DC - Server 2022). nxc returns Kerberos SessionError: KDC_ERR_ETYPE_NOSUPP(KDC has no support for encryption type). Target user's msDS-SupportedEncryptionTypes 0

Screenshots (if appropriate):

Before Fix:

Impacket GetUserSPNs.py results while not using -no-rc4

Impacket GetUserSPNs.py results while using -no-rc4

After Fix:

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)

[mpgn]

CIA lvl reporting 🥷

[NeffIsBack]

Thanks for the PR!

Tho I don't think the core issue is that RC4 is forced in the request. getTGT should always renegotiate AES if RC4 is denied and I am also able to request both RC4 and AES tickets:

Can you troubleshoot what part exactly fails here? So what exactly the returned TGT/ST ciphers are?

[mpgn]

Thanks for the PR!

Tho I don't think the core issue is that RC4 is forced in the request. getTGT should always renegotiate AES if RC4 is denied and I am also able to request both RC4 and AES tickets:

Can you troubleshoot what part exactly fails here? So what exactly the returned TGT/ST ciphers are?

i thinks that because RC4 is simply disabled in his case while it's not in your labi could be wrong 🤔

[gitgotgitgotit]

My co-worker had what seems the same problem. I l
Might be related to updates where they don’t want RC4 in Kerberos. MS article:
https://techcommunity.microsoft.com/discussions/microsoft-security/kerberos-and-the-end-of-rc4-protocol-hardening-and-preparing-for-cve%E2%80%912026%E2%80%9120833/4502262

[termanix]

My co-worker had what seems the same problem. I l Might be related to updates where they don’t want RC4 in Kerberos. MS article: https://techcommunity.microsoft.com/discussions/microsoft-security/kerberos-and-the-end-of-rc4-protocol-hardening-and-preparing-for-cve%E2%80%912026%E2%80%9120833/4502262

Right, turns out this is literally MS's RC4 hardening rollout. When msDS-SupportedEncryptionTypes is unset/0 the KDC now defaults to AES-only that's exactly why the target refuses RC4 despite attr=0.
In my scenario my login account still gets RC4 because its etypes still include it; the target with attr=0 falls into the new AES-only default. Strengthens the case for handling it (in nxc or impacket) since every RC4-forcing flow will increasingly hit this.

Talked with Neff about that. Here is some explanation;

• RC4 TGT belongs to the requesting account (which supports RC4); it says nothing about the target. The target (msDS-SupportedEncryptionTypes = 0, it means AES-only via the domain default) has no RC4 key, so an RC4-only TGS-REQ returns ETYPE_NOSUPP. Getting an RC4 TGT and reaching an AES-only ST are two different accounts' etypes.

In impackets kerberosv5 file, AES not in etype

And cause of that

I think It's general, not roast-specific: any ST request from an RC4 TGT to an AES-only service fails the same way (incl. PtH-over-Kerberos). Normal password/AES login negotiates an AES TGT, so it works fine.

We last discussed that we would try to fix the issue on the Impacket side when Neff becomes available.