feat: Compute gMSA AES keys when using --gmsa

[Ne0re0]

Description

This PR computes both aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 keys when using --gmsa with nxc ldap, provided the specified user has ReadGMSAPassword rights over a gMSA account.

This is a re-implementation of the logic from the gMSADumper tool.

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

To test this, you need a user with ReadGMSAPassword rights over a gMSA account. Run:

nxc ldap <target> -u <user> -p <password> --gmsa

Screenshots (if appropriate):

Checklist:

• I have run Ruff against my changes (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 describing 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]

Hi and thanks for the PR.

Nice idea, but what is 988131e about? Please also elaborate the use of AI, as requested in the PR template:

NetExec/.github/PULL_REQUEST_TEMPLATE.md

Line 5 in b77744f

If you have used AI in any form, please state the tool you used (e.g. Claude Code, Cursor, Amp) along with the extent that the work was AI-assisted. See the project's AI policy for more details: https://github.com/Pennyw0rth/NetExec/blob/main/AI_POLICY.md

[Ne0re0]

Hi!

Oops, I didn't realize commits to the same branch would sync directly to this PR. Sorry about that... The extra changes were entirely claude coded and not meant to be included.

I'll revert it back to the first commit. Would you prefer a fresh PR or should we continue with this one?

[NeffIsBack]

Hi!

Oops, I didn't realize commits to the same branch would sync directly to this PR. Sorry about that... The extra changes were entirely claude coded and not meant to be included.

I'll revert it back to the first commit. Would you prefer a fresh PR or should we continue with this one?

Absolutely fine to continue on in here👍

[ThatTotallyRealMyth]

Hey! I pr'ed an gmsadump script to impacket and I think it might be helpful for this :3 fortra/impacket#2171

We can simply use the generate_kerberos_keys() from impacket.krb5.crypto function to get the ntlm, aes128 and aes256 creds from the password blob

[carterleehaney]

This would be awesome to have :)

Anything I can do to help get this merged?

[NeffIsBack]

This would be awesome to have :)

Anything I can do to help get this merged?

You could try if it would make sense to integrate the generate_kerberos_keys() function by @ThatTotallyRealMyth. Besides that I just need to find the time to take a look at this

[Ne0re0]

This would be awesome to have :)
Anything I can do to help get this merged?

You could try if it would make sense to integrate the generate_kerberos_keys() function by @ThatTotallyRealMyth. Besides that I just need to find the time to take a look at this

o/,

Shouldn't we wait for the @ThatTotallyRealMyth's PR to be merged?

[ThatTotallyRealMyth]

This would be awesome to have :)

Anything I can do to help get this merged?

You could try if it would make sense to integrate the generate_kerberos_keys() function by @ThatTotallyRealMyth. Besides that I just need to find the time to take a look at this

o/,

Shouldn't we wait for the @ThatTotallyRealMyth's PR to be merged?

The generate_kerberos_keys function lives in impacket, and not my PR. You could simply call it directly right now and get the nt hash and aes keys directly without adding custom logic

[NeffIsBack]

Implemented the compute_kerberos_keys(), LGTM now:

@mpgn any chance you still have a deployed GMSA that you could try to manually decrypt? It should work but I haven't tested it.

[NeffIsBack]

@Marshall-Hallenbeck we also need your feedback, there is still a pending change request

[Copilot]

Pull request overview

This PR extends the LDAP gMSA enumeration/decryption functionality to compute Kerberos AES128/AES256 keys (in addition to the existing RC4/NTLM-derived key) when --gmsa is used, reusing Impacket Kerberos key derivation.

Changes:

• Added Kerberos key derivation via impacket.krb5.crypto.generate_kerberos_keys and introduced a helper to compute RC4/AES keys from msDS-ManagedPassword data.
• Updated --gmsa output to include AES128/AES256 keys when readable.
• Updated --gmsa-decrypt-lsa to reuse the same key derivation logic and switched the LDAP search to the wrapper self.search().

Comments suppressed due to low confidence (1)

nxc/protocols/ldap.py:1404

• This debug log reports len(gmsa_accounts) (raw LDAP response entries), which can include non-entry records (e.g., references) and will be inconsistent with other methods in this file that log parsed entry counts. Consider logging len(gmsa_accounts_parsed) instead for an accurate record count.

                gmsa_accounts_parsed = parse_result_attributes(gmsa_accounts)
                if gmsa_accounts_parsed:
                    self.logger.debug(f"Total of records returned {len(gmsa_accounts):d}")

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[NeffIsBack]

LGTM: