Web Discovery with nimux HTTP and DNS

Overview

nimux 1.0.5 adds a lightweight web discovery layer to the existing AD and protocol command surface. The goal is not to turn nimux into a heavy web vulnerability scanner. The goal is to give an operator a fast, scriptable way to answer the first web questions without leaving the same toolkit used for SMB, LDAP, Kerberos, WinRM, and post-authentication validation.

The new HTTP and DNS paths cover:

• HTTP probing.
• Directory discovery.
• File discovery with extension expansion.
• Virtual host discovery.
• DNS subdomain discovery.
• Worker-based concurrency.
• Baseline and auto-calibration for wildcard responses.
• Response-size filtering with -fs.
• Status, length, and regex match filters.
• Link extraction.
• Recursive discovery with depth limits.
• Resume support for long wordlists.

Use these features only against systems you own or are explicitly authorized to assess.

Why add web discovery to nimux?

Internal environments often mix Active Directory, SMB shares, WinRM, IIS, management portals, forgotten virtual hosts, and service-specific web panels. An operator may start with a domain controller, discover IIS on 80 or 443, find a host header dependency, then pivot into LDAP, SMB, or ADCS. Before 1.0.5, nimux could see HTTP as a probe, but it did not provide enough web enumeration to stay in one workflow.

The 1.0.5 additions make the early web phase practical:

nimux http app.corp.local --path /
nimux http app.corp.local --dirs words.txt --workers 80
nimux http 10.10.10.10 --vhosts vhosts.txt --host corp.local --auto-calibrate
nimux dns corp.local --subdomains subdomains.txt --workers 200

This is intentionally focused. It helps find exposed paths and names. It does not try to exploit application bugs, submit forms, fuzz every parameter, or replace a dedicated web application scanner.

Start with a probe

Begin with a simple HTTP or HTTPS probe. Confirm the target, server behavior, redirect pattern, and default status before using a large wordlist.

nimux http web01.corp.local
nimux http web01.corp.local --path /login
nimux http web01.corp.local --ssl --path /

If the site lives on a non-standard port:

nimux http web01.corp.local --port 8080 --path /
nimux http web01.corp.local --ssl --port 8443 --path /

Basic authentication is supported for simple protected areas:

nimux http web01.corp.local -u operator -p '<password>' --path /admin

If the target needs a custom request header, add it explicitly:

nimux http web01.corp.local --header 'X-Forwarded-For: 127.0.0.1' --path /

The probe step gives you a baseline for later filtering. Record the status code, content size, and any redirect behavior before running discovery.

Directory discovery

Directory discovery uses a wordlist and checks candidate paths.

nimux http web01.corp.local   --dirs /usr/share/seclists/Discovery/Web-Content/common.txt   --workers 60

For IIS-heavy environments, use a list that includes Windows-oriented names:

nimux http web01.corp.local   --dirs /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt   --workers 80   --status 200,301,302,401,403

The status filter keeps output focused. During internal work, 401 and 403 are often useful because they reveal protected areas, not just accessible content.

File discovery and extension expansion

File discovery is useful when the application exposes backup files, scripts, static config, old handlers, or deployment leftovers.

nimux http web01.corp.local   --files words.txt   --extensions aspx,ashx,config,txt,bak,old   --workers 80

For PHP targets:

nimux http app.corp.local   --files words.txt   --extensions php,inc,txt,bak,zip   --workers 80

For mixed application stacks:

nimux http app.corp.local   --files words.txt   --extensions php,aspx,jsp,js,json,xml,txt,bak,zip   --workers 100

Keep extension lists intentional. A huge extension set multiplies requests quickly, creates noisy traffic, and makes false positives harder to triage.

Virtual host discovery

Virtual host discovery is one of the most useful additions in 1.0.5. It lets you test hostnames against a single IP by changing the Host header.

nimux http 10.10.10.10   --vhosts subdomains.txt   --host corp.local   --workers 100   --auto-calibrate

The --host value is the base domain used to build candidates from the wordlist. A word such as admin becomes admin.corp.local.

If your wordlist already contains full names, use it directly:

nimux http 10.10.10.10   --vhosts full-vhosts.txt   --workers 100   --auto-calibrate

When a server returns the same page for every host header, --auto-calibrate helps suppress the default response.

DNS subdomain discovery

The DNS path is separate from HTTP vhost discovery. DNS answers the question: which names resolve? HTTP vhost discovery answers: which host headers behave differently on this web server?

nimux dns corp.local   --subdomains /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt   --workers 200

Point at a specific resolver when testing an internal domain:

nimux dns corp.local   --server 10.10.10.10   --subdomains subdomains.txt   --workers 200   --json

Good workflow:

1. Run DNS subdomain discovery against the internal resolver. 2. Save resolving names. 3. Feed likely web names into HTTP probing. 4. Run vhost discovery against shared web IPs.

False positives and default responses

Modern web stacks often return a valid-looking page for every unknown path. Without filtering, every word in the list becomes a false positive.

Use --auto-calibrate first:

nimux http web01.corp.local   --dirs words.txt   --auto-calibrate

If you already know the default response size, use -fs:

nimux http web01.corp.local   --dirs words.txt   -fs 1234

The long option is equivalent:

nimux http web01.corp.local   --dirs words.txt   --filter-size 1234

Use regex filters when the default page contains stable text:

nimux http web01.corp.local   --dirs words.txt   --filter-regex 'not found|default site|unknown host'

For precise matching, combine filters:

nimux http web01.corp.local   --dirs words.txt   --status 200,301,302,401,403   --hide-status 404   --filter-size 1234   --workers 80

This is the difference between useful output and a screen full of noise.

Link extraction and recursion

--extract-links asks nimux to parse discovered pages for links. --recursion allows discovered paths to become new discovery roots. Use a depth limit so the run stays controlled.

nimux http web01.corp.local   --dirs words.txt   --extract-links   --recursion   --depth 2   --auto-calibrate

Recursion is useful for documentation portals, admin panels, and simple static sites. It is less useful for large dynamic applications where every page contains many parameterized links.

Keep the depth low during the first pass. Increase only when results justify it.

Resume and long runs

Large wordlists take time. Resume support lets an interrupted run continue without starting from zero.

nimux http web01.corp.local   --dirs big.txt   --workers 100   --resume web01-dir-run.jsonl

Use clear output names:

• web01-dirs.jsonl
• portal-vhosts.jsonl
• corp-dns-subdomains.jsonl
• intranet-files.jsonl

During reporting, those names make it obvious which run produced which finding.

Tuning workers and rate

Workers make discovery fast, but speed is not always the right goal. Internal services may be fragile. VPN links may be slow. Shared labs may rate-limit or drop traffic.

Start moderate:

nimux http web01.corp.local --dirs words.txt --workers 40

Increase when stable:

nimux http web01.corp.local --dirs words.txt --workers 120

Use rate limiting when the target should be touched gently:

nimux http web01.corp.local --dirs words.txt --workers 50 --rate 20

The right setting is the one that produces complete, repeatable results without destabilizing the service or the route.

Example workflow

A clean web discovery workflow can look like this:

nimux scan 10.10.10.10 --port 80,443,8080,8443 --open

nimux http 10.10.10.10 --path / --json

nimux dns corp.local   --server 10.10.10.10   --subdomains subdomains.txt   --workers 200   --json > corp-dns.jsonl

nimux http 10.10.10.10   --vhosts subdomains.txt   --host corp.local   --auto-calibrate   --workers 100   --json > web-vhosts.jsonl

nimux http portal.corp.local   --dirs directories.txt   --files files.txt   --extensions aspx,config,txt,bak,zip   --status 200,301,302,401,403   --auto-calibrate   --workers 80   --json > portal-content.jsonl

Then review the results manually before moving into authentication or application-specific testing.

Reporting

For each web discovery finding, include:

• Target host or IP.
• Port and scheme.
• Host header, if vhost discovery was used.
• Wordlist and filters.
• Status code.
• Response size.
• Evidence path.
• Why the path matters.

Avoid reporting every 200 response as a finding. A useful finding explains impact: exposed admin interface, sensitive backup, unauthenticated portal, internal service metadata, or a hostname that expands the attack surface.

Final thoughts

The 1.0.5 web layer is deliberately pragmatic. It gives nimux enough HTTP and DNS discovery to support real operator workflows without pretending to be a full application scanner. Use it to find names, paths, files, and protected areas. Then bring the rest of nimux to the services and identities those discoveries expose.