From Enumeration to Remote Shell with nimux

Overview

Many tools are strong at one phase of an assessment. One scanner finds ports. Another tool validates SMB. Another opens a shell. Another moves files. The workflow works, but the operator has to translate context between each tool. nimux is designed to keep that chain in one command surface.

This article walks through a practical authorized workflow: start with discovery, identify useful services, validate credentials, move into remote execution, transfer files when needed, and clean up after the test. The commands use neutral hostnames and placeholder credentials. Run them only in environments where you have explicit authorization.

Start with a narrow scan

The first mistake in many internal assessments is scanning too broadly too early. A narrow scan gives useful signal without producing unnecessary noise.

nimux scan 10.10.10.0/24 --port 53,88,135,139,389,445,464,5985,3389 --open

If you already know the target host, reduce scope further:

nimux scan dc01.corp.local --port 88,135,389,445,464,593,5985 --open

Good initial targets are services that identify domain infrastructure and remote management paths:

• Kerberos on 88.
• LDAP on 389 or LDAPS on 636.
• SMB on 445.
• WinRM on 5985 or 5986.
• RDP on 3389.
• MSSQL on 1433 or named instances.

The goal is not to prove everything at once. It is to decide which protocol path deserves the next check.

Fingerprint SMB and domain context

SMB usually gives fast information about signing, domain names, hostnames, and authentication behavior.

nimux smb dc01.corp.local

With credentials, move into share and policy checks:

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

If the engagement allows hash authentication:

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

This step answers basic questions:

• Is SMB signing required?
• Does authentication work?
• Which shares are visible?
• Are active sessions exposed?
• What password and lockout policy applies?

These answers affect later choices. For example, lockout-aware spraying should respect the domain policy. Remote execution should be attempted only after a clear authorization path exists.

LDAP enumeration

LDAP provides the directory view. Start with read-only queries before any write operation.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' --dcs

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

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' --kerberoast

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' --asreproast

For more controlled searches, use filters:

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

Keep raw LDAP output in files when you are comparing states:

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

JSON output makes the results easier to diff, parse, and include in later documentation.

Check WinRM before opening a shell

Remote shell access should be deliberate. First validate that WinRM is reachable and that authentication succeeds with a low-impact command.

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

For Kerberos:

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

If whoami works, run a second command that confirms hostname and context:

nimux winrm host01.corp.local -d corp.local -u operator -p '<password>' \
  --cmd hostname

Only then open an interactive shell:

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

This staged approach prevents confusion. If shell creation fails, you already know whether basic authentication and command execution worked.

File movement

File transfer should be purposeful. Do not upload tools by habit. When file movement is required, prefer predictable paths and cleanup.

SMB upload pattern:

nimux put fileserver.corp.local -d corp.local -u operator -p '<password>' \
  --share C$ \
  --local ./payload.bin \
  --remote Windows\\Temp\\payload.bin

SMB download pattern:

nimux get fileserver.corp.local -d corp.local -u operator -p '<password>' \
  --share C$ \
  --remote Windows\\Temp\\result.txt \
  --local ./result.txt

WinRM shell transfer helpers can be used inside interactive sessions. Keep filenames neutral and record what was moved, where it was placed, and when it was removed.

Remote execution alternatives

WinRM is not the only execution path. In authorized environments, the available path depends on firewall rules, service configuration, credentials, and host controls.

SCM execution:

nimux scm host01.corp.local -d corp.local -u operator -H <nt_hash> \
  --cmd 'whoami'

Helper service execution:

nimux bin host01.corp.local -d corp.local -u operator -p '<password>' \
  --cmd 'ipconfig /all'

Task Scheduler execution:

nimux tsch host01.corp.local -d corp.local -u operator -p '<password>' \
  --cmd 'hostname'

MSSQL command execution when explicitly in scope:

nimux mssql sql01.corp.local -d corp.local -u sql_operator -p '<password>' \
  --cmd 'whoami'

Each execution method has a different event footprint and failure mode. The operator should choose the least disruptive path that satisfies the assessment objective.

Working through a pivot

If the target is only reachable through a pivot, keep the same chain but add --proxy to supported commands.

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

nimux winrm adminhost.mgmt.local -d mgmt.local -k \
  --ccache operator.ccache \
  --proxy socks5://127.0.0.1:1088 \
  --cmd whoami

Do not hide the pivot in your notes. Record the route, SOCKS port, pivot host, and cleanup command.

Evidence and reporting

Strong reports do not only list commands. They connect commands to findings.

Useful evidence includes:

• Service discovery output.
• Authentication success or failure.
• Directory query results.
• Remote command context.
• File transfer paths.
• Cleanup proof.

A concise evidence note might say:

> Authenticated WinRM command execution was validated on host01.corp.local using the authorized operator account. The command returned the expected domain context and hostname. No persistent service was created for this check.

That is better than only pasting terminal output because it explains scope and impact.

Cleanup checklist

Before leaving a host or route:

• Remove uploaded files.
• Stop helper services.
• Kill SOCKS helpers.
• Delete temporary output files when appropriate.
• Export required evidence.
• Clear local temporary files that contain credentials or tickets.
• Record cleanup completion.

nimux can help with several of these steps, but cleanup is ultimately an operator responsibility.

Final workflow summary

A clean enumeration-to-shell workflow is staged:

1. Scan narrowly. 2. Fingerprint SMB and domain context. 3. Run read-only LDAP queries. 4. Validate credentials with low-impact commands. 5. Open a shell only after command execution is proven. 6. Move files only when needed. 7. Route through pivots explicitly. 8. Clean up and document.

That sequence keeps the assessment controlled and repeatable.