Back to blog
Aug 10, 202620 min read

SMB Share Enumeration and Spidering with nimux

A deep guide to the nimux 1.0.5 SMB share enumeration, anonymous/null-session checks, read-only spider mode, interesting-file triage, and reporting workflow.

SMBShare spiderEnumerationv1.0.5

Overview

SMB is still one of the highest-signal protocols in internal assessments. It identifies Windows domains, exposes share names, reveals access boundaries, and often contains the operational files that explain how an environment works.

nimux 1.0.5 improves this area in two important ways:

  • anonymous and null-session share enumeration is handled correctly;
  • --spider adds read-only recursive share triage with filters.

This article covers the practical workflow: negotiate SMB, list shares, test null-session behavior, spider readable shares, filter interesting files, and turn the results into useful evidence.

Use these commands only in authorized environments.

Start with SMB negotiation

Always begin with the cheapest check:

nimux smb fileserver.corp.local

This tells you whether SMB is reachable and gives basic metadata such as dialect, domain, hostname, and signing behavior when available.

For a domain controller:

nimux smb dc01.corp.local

For an IP:

nimux smb 10.10.10.10

Record:

  • SMB dialect.
  • Domain name.
  • Hostname.
  • Signing required or not.
  • Whether the host allows any anonymous information.

This initial fingerprint shapes the rest of the run.

Anonymous and null-session share enumeration

One of the 1.0.5 fixes is that anonymous/null-session share checks now show readable shares correctly instead of stopping at the negotiation banner.

Run:

nimux smb fileserver.corp.local --shares

If a share is visible or readable without credentials, nimux should report that state. This is useful for identifying accidentally exposed shares such as:

  • SYSVOL
  • NETLOGON
  • IPC$
  • public support shares
  • deployment shares
  • documentation shares
  • backups or transfer folders

Anonymous readability does not automatically mean sensitive exposure, but it is always worth triage.

Authenticated share enumeration

With valid credentials:

nimux smb fileserver.corp.local   -u operator   -p '<password>'   -d corp.local   --shares

With NTLM hash:

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

With Kerberos:

nimux smb fileserver.corp.local   -k   --ccache operator.ccache   -d corp.local   --shares

Share enumeration answers the first access question: what can this identity see?

Read-only spidering

--spider recursively lists content without downloading files.

nimux smb fileserver.corp.local   --spider   --share Public   --max-depth 3

Authenticated:

nimux smb fileserver.corp.local   -u operator   -p '<password>'   -d corp.local   --spider   --share Department   --max-depth 4

Start with a low depth. A large file share can contain hundreds of thousands of entries. Controlled depth gives fast signal without turning the run into a crawl of the entire file server.

Good starting values:

  • --max-depth 2 for broad share review.
  • --max-depth 3 for departmental shares.
  • --max-depth 4 only after you know the share is manageable.

Spider one path inside a share

Use --remote when you already know the interesting folder:

nimux smb fileserver.corp.local   --spider   --share Public   --remote 'IT/Deployments'   --max-depth 3

This is cleaner than spidering the whole share when a previous result or user report points at a specific directory.

Pattern filtering

Use --spider-pattern to restrict the names shown.

PDFs:

nimux smb fileserver.corp.local   --spider   --share Public   --spider-pattern '*.pdf'

Configuration files:

nimux smb fileserver.corp.local   --spider   --share Public   --spider-pattern '*.config'

Backups:

nimux smb fileserver.corp.local   --spider   --share Public   --spider-pattern '*.bak'

This is useful when you need a focused result set for a report or a quick check.

Interesting-file triage

--interesting applies a broad set of filename and extension patterns that commonly matter during authorized review.

nimux smb fileserver.corp.local   --spider   --interesting

Limit size to avoid huge artifacts:

nimux smb fileserver.corp.local   --spider   --interesting   --size-limit 10485760

The interesting matcher includes categories such as:

  • Windows config: .ini, .config, .xml, .json, .yml, .yaml.
  • Environment and secrets-like files: .env, .properties, key material.
  • Scripts: .ps1, .bat, .cmd, .vbs, .js, .py, .sh.
  • Certificates and keys: .pfx, .p12, .pem, .key, .crt, .cer.
  • Databases: .sqlite, .db, .mdb, .accdb.
  • Archives: .zip, .7z, .rar, .tar, .gz.
  • Documents: .pdf, .doc, .docx, .xls, .xlsx, .ppt, .pptx.
  • Windows binaries and installers: .exe, .dll, .msi.
  • Linux packages and binaries: .deb, .rpm, .AppImage.
  • macOS artifacts: .plist, .dmg, .pkg.

This is not a proof that a file is sensitive. It is a triage shortcut that helps decide what deserves manual review.

Combine share enumeration and spidering

A practical SMB workflow:

nimux smb fileserver.corp.local --shares
nimux smb fileserver.corp.local   --spider   --share Public   --max-depth 2
nimux smb fileserver.corp.local   -u operator   -p '<password>'   -d corp.local   --shares
nimux smb fileserver.corp.local   -u operator   -p '<password>'   -d corp.local   --spider   --interesting   --max-depth 3   --size-limit 10485760

This separates unauthenticated exposure from authenticated access. Reports should keep those states separate.

JSON output for evidence

Use JSON when you want repeatable evidence or post-processing:

nimux smb fileserver.corp.local   -u operator   -p '<password>'   -d corp.local   --spider   --interesting   --json > smb-interesting.jsonl

JSON output can be filtered later by path, share, file extension, size, or match reason.

Useful output files:

  • fileserver-shares.jsonl
  • fileserver-public-spider.jsonl
  • fileserver-interesting.jsonl
  • dc01-sysvol-spider.jsonl

SYSVOL and NETLOGON review

Domain controllers usually expose SYSVOL and NETLOGON. These are expected, but their contents still matter.

nimux smb dc01.corp.local --spider --share SYSVOL --max-depth 4
nimux smb dc01.corp.local --spider --share NETLOGON --max-depth 3

Look for:

  • old scripts;
  • deployment commands;
  • hardcoded paths;
  • references to service accounts;
  • legacy installer locations;
  • policy artifacts;
  • password-like strings in old files.

Do not assume every file is a finding. The finding is the sensitive content or unsafe operational pattern, not the existence of SYSVOL itself.

Support and tools shares

Support shares often contain the most useful context:

nimux smb fileserver.corp.local --spider --share support-tools --interesting

Common discoveries include:

  • remote support scripts;
  • local admin tooling;
  • installers;
  • database clients;
  • exported configs;
  • internal documentation;
  • legacy binaries.

These files can explain how admins manage the estate. Handle them carefully and avoid executing anything from a share unless the engagement explicitly permits it.

Kerberos and SMB spidering

If the environment requires Kerberos, use a ccache:

nimux smb fileserver.corp.local   -k   --ccache operator.ccache   -d corp.local   --spider   --share Department   --interesting

If Kerberos fails, check:

  • the target hostname matches the CIFS SPN;
  • the ccache exists;
  • the realm casing is correct;
  • the KDC is reachable;
  • time is synchronized;
  • /etc/hosts or DNS resolves the same name used in the ticket.

Most Kerberos SMB issues are name or realm mismatches, not spidering problems.

OPSEC and scope

SMB spidering can touch many files quickly. Keep it scoped:

  • Start with --shares.
  • Spider only readable shares.
  • Use --max-depth.
  • Use --interesting for triage.
  • Use --size-limit.
  • Avoid downloading files unless required.
  • Avoid writing to shares during enumeration.

This makes the workflow safer and easier to justify in a report.

Reporting

For share findings, report:

  • target host;
  • share name;
  • authentication context;
  • readable or listable state;
  • path;
  • file size;
  • why the file or folder matters;
  • whether access was anonymous, domain-user, or privileged;
  • exact nimux command used.

Separate exposure from sensitivity. A readable share is an exposure. A readable password file, private key, deployment script, or backup is the sensitive finding.

Final thoughts

SMB enumeration is most valuable when it stays disciplined. The 1.0.5 changes make nimux better at that discipline: list shares, spider read-only, filter aggressively, and keep evidence tied to the identity used. That is more useful than dumping a giant tree of filenames with no context.