Winrm relay newmodule

[overgrowncarrot1]

Description

New module that relays from a target machine on a network to other machines. This allows for one connection to be made, and then information relayed utilizing new-pssession and scriptblock. This can be used to go from external to internal machines, one domain to another domain and so on. The script does a Reverse DNS lookup so kerberos is used, nothing needs to be added to trusted hosts. The script also allows for the user to change what domain to go to, what username / password to use and also what command to run on a target machine. Machines do need to be allowed to talk to each other over windows remote management. This means having servers utilized instead of host machines.

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
• [x] This requires a third party update (requires pywinrm on attackers system)

Setup guide for the review

The attackers machine needs pywinrm, this is not installed by default on new Kali builds. Other than that, I used GOAD to show the winrm_relay.

In particular:

• Added Feature/Enhancement: Added Windows Relay module.

The script utilizes <hostname/ip>::::. As shown below with the options we are using an IP address (reverse DNS lookup happens), then on the other machine (kingslanding) we are utilizing the hostname.

nxc winrm 192.168.56.11 -u vagrant -p vagrant -M winrm_relay -o REMOTE='192.168.56.12:admin:P@ssw0rd!:ESSOS.LOCAL:whoami;hostname','KINGSLANDING:admin:P@ssw0rd!:sevenkingdoms.local:hostname'

Screenshots (if appropriate):

Screenshots are always nice to have and can give a visual representation of the change. If appropriate include before and after screenshot(s) to show which results are to be expected.

Wireshark shows other machine did not directly connect to kali, the commands were relayed to the other machine.

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)
• [x] 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)
• [x] 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
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation (PR here: https://github.com/Pennyw0rth/NetExec-Wiki)

[NeffIsBack]

Hi thanks for the PR.

A few points:

• If you need pywinrm please add that to the dependencies with poetry add pywinrm or the dependency management tool of your choice
• It looks like there are added commands in the test file from previous PRs? Please remove anything that isn't related to this PR
• Please use the build in option parsing instead of building another option parsing system on top of it. E.g. the current implementation would not accept passwords containing the : character
• Maybe i am misunderstanding something here, but this looks like remote command execution/pivoting instead of classical "relaying". What of the two is it?

[Dfte]

Hey!

I don't really understand what this module is used for to be honest. Why would you bother having such a module while you can already do something like:

nxc smb IP -X "Invoke-Command username:password cmd" 

Isn't too much ?

[overgrowncarrot1]

Hey!

I don't really understand what this module is used for to be honest. Why would you bother having such a module while you can already do something like:

nxc smb IP -X "Invoke-Command username:password cmd" 

Isn't too much ?

You are 100 precent correct, that is not too much. This module utilizes the winrm connection made in the beginning, utilizes invoke-command with script block to send to other machines. It also does a reverse DNS lookup and can be used for send different commands / users / passwords to those to other machines. Each machine then connects back to the first Windows machine which then relays the information back to your kali machine. So instead of having to do $password = ..... and then $cred = ..... and then invoke-command -cred $cred -script block ... this does it for you.

Shown in the screenshot below we are going from the vagrant user for inital login to .11, then sending new commands for the admin user on .12, then from .11 using vagrant user on .10, lastly again forwarding from .11 to admin user on .22. Since this is also for winrm, the user technically does not need to be an administrator, they would need to be within the remote management group on those different machines.

I thought it was good, but if you all do not see a place within netexec for it, I will not lose sleep at night, lol, you are all doing some amazing work on this tool.

I have also fixed the options portion and fixed when a user uses -x or -X, and also did the add pywinrm if you wanted me to do the latest PR.

[Dfte]

Okay I got the idea, basically you are jumping from one host (the one from nxc winrm) to other ones using the invoke command. I like that but I'd rename the module to winrmjump or something as winrm_relay looks more like something related to ntlmrelayx and coerces.

What do you think ?

[overgrowncarrot1]

Sounds good, I changed then name to winrmjump, fixed the options and changed e2e_commands.txt. I was also able to update it to allow for -x or -X and REMOTE_COMMANDS. Will do a PR for wiki when time allows.