Added MSRPC protocol

[kasem545]

Description

This PR adds a new MSRPC protocol to NetExec, providing direct RPC-based enumeration and management operations via SAMR (Security Account Manager Remote) and LSA (Local Security Authority) interfaces.

Key Features:

• Authentication: Plaintext, NTLM hash, and Kerberos support with anonymous enumeration where allowed
• Enumeration: Users, groups, domains, trusts, shares, sessions, password policies, RID brute-forcing
• LSA Operations: SID/name lookups, privilege enumeration, account rights, security descriptor parsing
• User Management: Create/delete/enable/disable users, password change/reset, modify user attributes
• Group Management: Create/delete groups, add/remove members

This provides rpcclient-equivalent functionality natively within NetExec, enabling direct RPC access without SMB overhead for scenarios where granular control over SAM/LSA operations is needed.

Dependencies: No new dependencies required - uses existing Impacket DCERPC libraries.

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Setup guide for the review

Testing Environment:

• Python: 3.10+
• OS: Linux (tested on Kali Linux)
• Targets: Windows Server 2019/2022 (Domain Controller and member server)

Testing the new RPC protocol:

# Basic connection test
nxc smb <target_ip> -u <user> -p <password>

# Enumeration (authenticated)

nxc smb <target_ip> -u <user> -p <password> --rpc-users
nxc smb <target_ip> -u <user> -p <password> --rpc-groups
nxc smb <target_ip> -u <user> -p <password> --rpc-pass-pol
nxc smb <target_ip> -u <user> -p <password> --rpc-trusts

# RID brute force (may work anonymously on misconfigured systems)
nxc smb <target_ip> -u '' -p '' --rid-brute 

# LSA operations

nxc smb <target_ip> -u <user> -p <password> --lsa-query
nxc smb <target_ip> -u <user> -p <password> --lsa-query-security

# User management (requires admin privileges)

nxc smb <target_ip> -u <admin> -p <password> --create-user testuser:'P@ssw0rd123'
nxc smb <target_ip> -u <admin> -p <password> --delete-user testuser 

# Hash authentication

nxc smb <target_ip> -u <user> -H <nthash> --users

Screenshots (if appropriate):

Checklist:

• 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: Added MSRPC protocol  NetExec-Wiki#83)

[XiaoliChan]

Stop doing vibe-coding, please

Now we have dcerpc(wmi), smb support, why U add rpc protocol?

[Dfte]

Having the RPC protocol could be useful in case the smb port is closed but this is a hugeeeee PR holy shit. @kasem545 can you provide screenshots on a test lab for each functions so that we don't have to make sure everything works ?

[NeffIsBack]

Hi and thanks for the PR.

This looks indeed a little AI generated. @kasem545 could you please provide information which parts are generated and which are coded by hand? Which have you tested? Please provide screenshots of your work and demonstrate how the proto looks like etc. Just posting a (probably also AI generated) function list into the PR description is not enough.

Also, we extensively use rpc inside of the SMB protocol. As @Dfte said it could be worth adding an rpc protocol for situations where SMB is not available, but we could also very well integrate that into the SMB protocol. Up for discussion if a whole new protocol makes sense for this.

[kasem545]

@XiaoliChan @NeffIsBack thanks for sharing your perspective on vibe coding. I understand the concerns around it, but that’s not what this was about. I was working on a box focused on RPC, As a heavy NetExec user, having everything in one place for penetration testing why not having RPC support , and this can inspire other programmers to work RPC and not vibe coding it
it may by a vibe code but it work this PR can be close but im keeping it.

Thanks @Dfte for supporting the idea

[NeffIsBack]

To prevent misunderstandings, I am not generally against using AI for coding. Personally I use AI for coding stuff all the time, but when it comes to huge PRs that in addition lack documentation I get hesitant because that is often a sign (but not a direct necessity) of low code quality and not or not enough testing.

Thanks for the screenshots, looks great :)
The remaining question would be if this should be a protocol on its own, or if we should continue integrating the RPC stuff into the SMB protocol. Everyone reading this, please share your thoughts.

[Dfte]

So my thougths are that if the RPC protocol relies only on Named Pipe, then we should migrate all functionalities to SMB. Because in the end, SMB port is required. If there are RPC endpoints that are not SMB, we can integrate them. For example, MS-Even interface exposes 3 endpoints, One Named pipe as well as one IP/Port (and one local rpc interface which we don't care about obviously):

As such, the RPC protocol could connect directly to that IP/port and in that case having the protocole is interesting!

[kasem545]

i done it so it be on its own protocol because RPC have large attack surfs, great thing can be achieved here

[Marshall-Hallenbeck]

@kasem545 can you use the template we have for PRs? It looks like you deleted it and just put down the flags, etc.

[XiaoliChan]

i done it so it be on its own protocol because RPC have large attack surfs, great thing can be achieved here

I get Ur innovation, but I think you can make the pr to smb.py or wmi.py instead of creating a new protocol, because the others users may have confused when using NXC

From smb to ncacn_np call, it have this transport.SMBTransport, from rpc to full smb call, it has this rpctransport.get_smb_connection

but why I said it’s dup? Because calling ncacn_np is same as calling smbconnection

https://github.com/fortra/impacket/blob/a0bc463baf9d9f6a4b4da6ebdc67da9f928ff502/impacket/dcerpc/v5/transport.py#L136

And if you check Ur history PR, you will find this one #534

The SMBTransport didn’t check any smb version, so it will lead to crash in real world attack, so for this PR, I suggest you can make the new ncacn_np pipe call function to smb.py instead of creating a dup protocol.

[kasem545]

@XiaoliChan i understand your concerns also i have refactored rpc.py to inherit from smb, so named pipe operations now reuse smb connection handling rather than creating duplicate logic this addresses the SMBTransport version issue you mentioned.

and but do you think doing nxc smb --rpc-* will be better approach ? and it doesn't get users confused??

[XiaoliChan]

and but do you think doing nxc smb --rpc-* will be better approach ? and it doesn't get users confused??

That is what I means, U can move the new funcs to smb.py, I check there are lots of new funcs which doesn't include in smb.py

For the nxc smb --rpc-*, we call it --pipe --pipe-method, for example, --pipe efsr --pipe-method EfsRpcOpenFileRaw (U may have a dictionary to map the method)

[XiaoliChan]

@kasem545 So now U have to de-duplicate the function, for example, like --rid-brute, maybe can remove the old rid-brute one (because U organize to the new rpc_enum.py), After that, I think would be better than before.

Don't forget remove the rpc structure from the old commit

[kasem545]

@XiaoliChan the rid-brute no longer reimplements RPC logic the SMB side only parses args and prints results all RPC functionality has been consolidated into rpc_enum.py via RPCEnumerator.

The RPC structure has been removed so there is now a single consistent RPC path shared with the other nxc smb --rpc-* commands.

[NeffIsBack]

Actually i don't agree on this one. We should not just label everyhing --rpc-* because this is not a lib that you should use to call RPC functions but a tool to abstract these RPC calls. We should check which functions make sense to integrate in what way. The user should no need to worry which rpc functions will get which information.

A few notes:

• Managing groups (adding/deleting/removing users and groups) could be a good module, but is duplicate to New Module add-group #688
• Changing passwords is duplicate to the change-password module
• Enumerating existing domain groups should probably be implemented using the --groups flag that originally hosted an LDAP based implementation
• Password policy enumeration already exists
• Trust enumeration via RPC could be a great addition (alternative to LDAP based)

What i want to say is that for each rpc function we must 1. check if it already exists and 2. if not see how we can integrate it in a way that makes sense (e.g. add a module, arg etc.) and is good to understand.