Add standalone --generate-st

[azoxlpf]

Description

Following the discussion on #1224, this change extends --generate-st so you can request a normal service ticket for any SPN (TGT + getKerberosTGS, same idea as Impacket’s getST.py) without --delegate, while keeping the existing S4U flow when --delegate is used. It also renames --delegate-spn to --spn, since that flag is no longer only about delegation, it is the SPN for both constrained-delegation/RBCD and plain ST export.

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

run nxc smb ip -u 'user' -p 'password' --generate-st user --spn 'CIFS/DC01.domain'

Screenshots (if appropriate):

With --delegate :

Without --delegate :

Checklist:

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

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

As always, thanks for the PR!

So my thoughts on this: Wouldn't it make sense if we would modify&PR to impacket that the generated/used ST in the kerberos authentication is set as self.__TGS and we simply exract that after successful auth and store it? Otherwise we would 1. do a second authentication attempt and 2. there is a lot of room for error when trying to recreate the original handshake (e.g. trust auth etc.).
Thoughts guys?

[azoxlpf]

As always, thanks for the PR!

So my thoughts on this: Wouldn't it make sense if we would modify&PR to impacket that the generated/used ST in the kerberos authentication is set as self.__TGS and we simply exract that after successful auth and store it? Otherwise we would 1. do a second authentication attempt and 2. there is a lot of room for error when trying to recreate the original handshake (e.g. trust auth etc.). Thoughts guys?

I agree storing the ST already obtains in self.__TGS after kerberosLogin and exporting it post-auth is the right default. I can open an Impacket PR for that and simplify NetExec to getCredentials() + ccache. For arbitrary --spn without an SMB session we’d still need either a dedicated path or extending kerberosLogin to accept a custom SPN