SOCKS Pivoting with nimux

Overview

Internal network access is often the point where an assessment stops being a list of open ports and starts becoming a real workflow. A single reachable host might have access to a management subnet, a staging domain, a backup segment, or a server VLAN that is not directly exposed to the operator machine. nimux includes SOCKS workflows so the same tool can help establish a pivot from Windows or Linux hosts and then route supported commands through that path with --proxy.

The goal is simple: create an operator-controlled SOCKS listener locally, start a controlled helper on an authorized host, then use that channel for follow-up enumeration and validation. This keeps pivoting close to the rest of the command surface. You do not have to switch mental models between discovery, authentication, execution, and routing.

When to use a SOCKS pivot

SOCKS pivoting is useful when a host can reach networks your workstation cannot reach directly. During an authorized assessment, that can include:

• A workstation that can reach a domain controller on another subnet.
• A server that can reach a backup or SQL network.
• A jump host with route access to an isolated management segment.
• A lab host used to validate multi-hop internal paths.

Before creating the pivot, validate authorization, scope, and cleanup expectations. A pivot changes network reachability, so it should be documented and removed when the workflow is complete.

Reverse pivot pattern

Reverse mode is useful when the target host can connect back to your operator system, but inbound access to the target is limited. The operator side listens for the helper callback and exposes a local SOCKS listener.

nimux socks 192.168.1.103 -u administrator -p '<password>' \
  --reverse \
  --listener 192.168.1.104 \
  --socks-port 1088 \
  --control-port 1081

Linux pivot hosts use the same reverse pattern, but the deployment transport is SSH and the command needs --linux.

nimux socks pivot01.lab.local --linux -u operator -p '<password>' \
  --reverse \
  --listener 192.168.1.104 \
  --socks-port 1088 \
  --control-port 1081

nimux socks pivot01.lab.local --linux -u operator --ssh-key ~/.ssh/id_rsa \
  --reverse \
  --listener 192.168.1.104 \
  --socks-port 1088 \
  --control-port 1081

The important values are:

• --listener is the operator IP the helper will call back to.
• --control-port is the reverse control transport.
• --socks-port is the local SOCKS5 port used by follow-up tooling.

When the helper connects, nimux prints the SOCKS endpoint and a cleanup command. Keep both in your notes. The cleanup command is part of the operational workflow, not an optional detail.

For Linux pivots, deployment currently expects reverse mode with --listener, and cleanup typically relies on the printed pid and remote helper path. Windows pivots may also print a scheduled task name.

Routing nimux through the pivot

After the pivot is active, supported nimux commands can use --proxy.

nimux scan 172.16.118.0/24 --port 445,389,5985 \
  --proxy socks5://127.0.0.1:1088

nimux smb dc04.mgmt.local -u operator -p '<password>' --shares \
  --proxy socks5://127.0.0.1:1088

nimux ldap dc04.mgmt.local -d mgmt.local -u operator -p '<password>' --trusts \
  --proxy socks5://127.0.0.1:1088

This is the main advantage of keeping the pivot inside the same toolkit. The operator does not need to rebuild the workflow around another proxy syntax for every stage.

Validation checklist

After starting a pivot, validate it with low-impact checks first:

• Confirm the SOCKS listener is active locally.
• Scan a small set of expected ports before scanning a wider range.
• Use hostnames only after DNS behavior is confirmed.
• Prefer explicit IP tests when DNS is not yet reliable.
• Record the process ID and remote helper path shown by nimux.
• Record the scheduled task name as well when the pivot host is Windows.

If DNS does not work through the route, use IP addresses first, then decide whether host mapping, resolver configuration, or an internal DNS route is appropriate for the engagement.

Cleanup

Every pivot should have a cleanup step. Use the kill command printed by nimux after deployment, then validate that the local SOCKS listener and remote helper are gone.

nimux socks 192.168.1.103 [auth] --kill --pid <pid> --socks-remote '<remote-helper-path>'

Linux cleanup normally looks like this:

nimux socks pivot01.lab.local --linux -u operator --ssh-key ~/.ssh/id_rsa \
  --kill --pid <pid> --remote '<remote-helper-path>'

Clean notes matter. They help prove that the pivot was authorized, temporary, and removed after use. That is part of professional operator discipline.

Designing a pivot plan before running commands

The strongest pivot workflow starts before the first command runs. Operators should know what route they are trying to open, which host will carry the route, which ports are expected to be useful, and what success looks like. Without that plan, pivoting can quickly become noisy and hard to explain in a report.

A practical plan answers these questions:

• Which host is allowed to run the helper?
• Which network or host should become reachable through the pivot?
• Which service checks are necessary?
• Which commands are read-only and which commands change state?
• How will the route be cleaned up?
• What evidence should be saved?

For example, if the goal is to validate whether a server can reach an internal domain controller, start with a narrow check against Kerberos, LDAP, SMB, and WinRM ports. Avoid broad scans until the route is proven and the rules of engagement allow it.

nimux scan 172.16.118.4 --port 88,389,445,5985 \
  --proxy socks5://127.0.0.1:1088 \
  --open

That command is small, targeted, and easy to explain. If it fails, the operator can troubleshoot the route, DNS, firewall behavior, or authentication without mixing in unnecessary traffic.

Forward and reverse thinking

The direction of the pivot matters. In some environments the operator can connect to the target host directly. In others, the target can only call back to the operator. Reverse mode exists for the second case.

The mental model is:

• Direct or forward workflow: the operator reaches the helper endpoint.
• Reverse workflow: the helper reaches back to the operator endpoint.
• Local SOCKS listener: follow-up tooling talks to the local SOCKS port.
• Control transport: the route that carries traffic between the helper and operator system.

If reverse mode does not connect, check simple causes first. Confirm the listener IP is reachable from the target. Confirm the control port is allowed outbound. Confirm the host firewall is not blocking the callback. Confirm the operator machine is listening on the expected interface, not only on loopback.

DNS and name resolution

Pivoting often exposes DNS problems. A route may pass TCP traffic but still fail name resolution. This is why nimux examples often show both hostnames and IP addresses.

Use a staged approach:

1. Validate raw IP reachability. 2. Validate the service port. 3. Validate authentication with an IP if the protocol allows it. 4. Validate hostname resolution. 5. Move to Kerberos only after SPN and DNS behavior are clear.

Kerberos is especially sensitive to names. If an operator requests a ticket for one SPN and then connects to a different hostname, the failure may look like an authentication problem even though the route is fine. When in doubt, keep the hostname, SPN, and DNS record aligned.

Using proxychains with the nimux SOCKS listener

nimux supports --proxy on supported commands, but there are times when another tool needs the same route. In that case, the SOCKS listener can be used with proxychains or another SOCKS-aware client.

The SOCKS line usually looks like this:

socks5 127.0.0.1 1088

Then a basic validation can run through the same path:

proxychains4 -q curl http://172.16.118.10:8080/

Keep this as a secondary option. The cleanest nimux workflow is still to use --proxy directly where supported, because the command output, JSON records, and operator notes remain in one syntax.

Operational safety

A SOCKS pivot can make internal networks reachable from tools that were never meant to touch those networks. Treat it as a controlled capability. Avoid leaving a browser, scanner, or background service configured to use the pivot after the assessment step is complete.

Useful safety controls include:

• Use a dedicated SOCKS port per assessment.
• Keep the proxy listener on loopback unless remote access is required.
• Do not reuse old proxychains configuration without checking it.
• Stop the pivot before switching to unrelated work.
• Keep terminal history clean of plaintext passwords when possible.
• Prefer scoped target lists over full internal ranges.

These habits reduce accidental traffic and make the engagement easier to defend if logs are reviewed later.

Reporting pivot findings

Pivot findings should explain what route was proven, not only that a proxy was started. A good report note includes:

• Pivot host.
• Pivot method.
• Local SOCKS endpoint.
• Internal subnet or host reached.
• Protocols validated.
• Cleanup status.
• Security implication.

For example:

> A SOCKS route was established through an authorized workstation and used to validate access to the internal management subnet. SMB and LDAP were reachable from the workstation context, demonstrating that compromise of that host can extend visibility into internal directory services. The helper was removed after testing.

That style is more useful than screenshots alone. It explains impact, scope, and cleanup.

Common mistakes

The common pivoting mistakes are predictable:

• Scanning too much too early.
• Forgetting to clean up the helper.
• Confusing listener IP with SOCKS listener IP.
• Using hostnames before DNS is understood.
• Forgetting to pass --proxy on follow-up commands.
• Treating a failed Kerberos command as a failed route.
• Leaving proxychains pointed at an old listener.

Most of these are process problems, not tool problems. nimux helps by printing route details and cleanup commands, but the operator still needs to keep the workflow disciplined.

Final thoughts

SOCKS pivoting is powerful because it changes reachability. That also makes it sensitive. The best use of nimux pivoting is narrow, documented, and temporary: open the route, validate what matters, route the next commands through --proxy, collect evidence, and clean up.

Used that way, pivoting becomes a controlled assessment technique rather than a messy background state.