Add targeted Kerberoasting by injecting/removing temporary SPNs

[azoxlpf]

Description

The attack is possible when the authenticated user has GenericAll, GenericWrite, WriteProperty, or Validated-SPN rights over a target account.

By adding a temporary SPN (ServicePrincipalName) to such a user, the account becomes Kerberoastable. The function requests a TGS for the injected SPN, extracts the hash, and immediately removes the SPN afterward to reduce detection.

Note: Once this PR is merged Allow for specifying specific users to kerberoast a follow-up update will introduce support for targeting a specific user, e.g.:

--targetedkerberoast --user tmoulin4 hashe.txt

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)
• [X] 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

Notes:

The current implementation uses a direct ldap3 bind for modifying SPNs. This only works when using NTLM authentication with username and password.

Kerberos authentication with ldap3 is problematic, as it relies on GSSAPI, which in turn depends on native system libraries like libkrb5 and gssapi bindings. This limits cross-platform compatibility, particularly in containerized or constrained environments.

To test the feature, use an account with permissions over user objects (e.g., Account Operators group). No additional GPO or registry changes are required.

Limitation:

To fully support all authentication methods (NT hash, AES key, kerberos ccache), the current workaround is to use NTLM (username + password). Integrating broader support would require implementing full LDAP authentication logic using Impacket, as ldap3 does not natively support these methods without relying on GSSAPI.

Screenshots (if appropriate):

The screenshot below demonstrates a successful targeted Kerberoasting attack. It shows:

• SPN injection on user accounts without existing SPNs.
• Successful TGS hash retrieval for offline cracking.
• Immediate SPN cleanup (removal) after extraction.

Checklist:

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

• [X] 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)

[azoxlpf]

In the description I said that “Kerberos authentication with ldap3 is problematic because it relies on native GSSAPI libraries (libkrb5, etc.).” That statement was wrong.

The new helper introduced in add ldap3 Kerberos authentication function performs a pure-Python SASL/GSS-SPNEGO bind through ldap3; it does not depend on any system libraries or extra packages. Once that PR is merged, this PR:

adds / removes the temporary SPN via the same ldap3 connection,

works with every credential type (password, NT hash, AES-128/256 key, ticket cache).

Therefore this PR depends on add ldap3 Kerberos authentication function

Below are two quick screenshots that prove the point:

AES 128 :

KCACHE :