Added --impersonate flag on mssql protocol

[T1erno]

Description

The --impersonate flag has been introduced in the MSSQL protocol, adding a first-level protocol-level way to set EXECUTE AS before executing any command arguments or modules
The mssql_priv module is not included in the impersonation flow; this recovers direct impersonation so that users can execute queries/modules with another login/user without additional module modifications

A module-only approach would be limited to module execution, and arbitrary arguments cannot be combined with modules. A protocol-level flag is applied universally and consistently across all CLI actions and modules, without the need to change each module or overload its options

This might be better than modifying the actual modules, which would only affect the internal logic of that module and still not change the session context for other actions. --impersonate sets the session context once, so all subsequent operations are executed under the intended login/user, in a more predictable and reusable way

As you can see in the image, the modules and queries are executed in the context of the impersonated user

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)

Screenshots (if appropriate):

Checklist:

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

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

[mpgn]

ok for me ✅

[NeffIsBack]

ok for me ✅

Sounds good, from my side as well. However the argument/module calling is done in the connection.py and should not be reimplemented here.

Thanks for the PR!

[Marshall-Hallenbeck]

@T1erno please add this new flag to the e2e tests

[NeffIsBack]

Really cool technique :)

One thought: Do we want to continue execution even if impersonation fails? My intuition would be no (and I think that is also the way it is currently implemented?), but let's discuss it. If we don't, we should just exit().

[T1erno]

Fixed, I think
Im not sure if the e2e command is correct or if it need another test user besides LOGIN_USERNAME

[NeffIsBack]

Im not sure if the e2e command is correct or if it need another test user besides LOGIN_USERNAME

No that's fine, thanks :)

[Dfte]

Hey dude! At this point, we should just get ride of the enum_impersonation module and have it as a core option directly! That's the kind of things I'm working on, for example with that PR #1271

Thoughts guyz ?

[NeffIsBack]

Hey dude! At this point, we should just get ride of the enum_impersonation module and have it as a core option directly! That's the kind of things I'm working on, for example with that PR #1271

Thoughts guyz ?

We could probably do something like:

• --impersonate enumerates possible enumerations
• --impersonate <user> would do the enumeration

Similar to --database

[Dfte]

Exactly what I was thinking of 👀 and then we can wrap every sql queries with a function that checks whether we rely on a linked server and/or impersonating someone ^^