Per-service deep enumeration after naabu port discovery (post-v2.0)

[ashok-kamat]

What

After naabu discovers open ports + service_detection classifies them, dispatch service-specific enumeration tools per service type — the way Tib3rius/AutoRecon does it. Today OpenEASD's pipeline goes naabu → nmap NSE vulners → done for non-web ports. There's a deeper layer between "I found a service" and "I scanned for CVEs against the banner version" that we're not exploring.

Concrete examples of per-service tools to dispatch:

Service detected	Tool to dispatch
SMB (445, 139)	enum4linux, smbclient, smbmap, nbtscan
SNMP (161 UDP)	snmpwalk with default community strings; onesixtyone
FTP (21)	nmap FTP NSE scripts; banner grab
MSSQL (1433)	nmap mssql NSE; impacket-mssqlclient for auth test
Postgres (5432)	nmap postgresql NSE
MySQL (3306)	nmap mysql NSE
RDP (3389)	nmap rdp NSE; rdesktop security check
LDAP (389, 636)	ldapsearch anonymous bind test
NFS (2049)	nmap nfs NSE; mount-list probe
Telnet (23)	banner grab; brute test (opt-in)

Why

Per-service enumeration is a real depth gap in our current pipeline. We do nmap NSE vulners on non-web ports, which catches version-string-matched CVEs, but we don't do the service-protocol-level enumeration that pen testers and ASM teams actually use to find exposure.

Concrete example: an SMB share with anonymous read enabled won't show up in our findings today. enum4linux would catch it in seconds. Same shape for SNMP with public community string, anonymous LDAP bind, default-credential MSSQL, anonymous FTP.

This is the single biggest depth gap we have versus tools like Tib3rius/AutoRecon (6k stars, OSCP-positioned). Closing it would meaningfully change the value prop: from "scan my external surface" to "scan my external surface AND tell me what's actually exposed at each service."

Hypothesis

A per-service enumeration phase (call it Phase 6.5 or split Phase 6 into 6a/6b) inserted between service_detection and nmap/tls_checker would:

1. Catch a class of exposure (anonymous shares, default-credential databases, weak LDAP) that's currently invisible to OpenEASD
2. Produce higher-confidence findings than NSE vulners alone — because we're proving the exposure exists, not just matching a version string
3. Position OpenEASD competitively against AutoRecon for the "deep enumeration" use case while keeping our continuous-monitoring + lifecycle differentiation
4. Fit cleanly into the existing plugin pattern — each per-service tool becomes its own apps/*/ directory with the standard four-file pattern

Evidence

Speculative on the impact magnitude — no data on how many real OpenEASD users have, say, anonymous SMB shares that would surface only through per-service enumeration. Could be ≤5% of scanned targets, could be 30%.

Data-oriented on the feature being absent — verified by inspecting apps/nmap/ (does NSE vulners, not per-service enum) and apps/service_detection/detector.py (classifies service type, but no downstream service-specific dispatch).

Data-oriented on the competitive gap — Tib3rius/AutoRecon's README explicitly enumerates feroxbuster (HTTP), smbclient (SMB), snmpwalk (SNMP), enum4linux (SMB), and dozens more.

Scope for v1

Pick the 5 most impactful services first. Suggested order based on real-world exposure patterns:

1. SMB (enum4linux + smbclient + smbmap) — anonymous-share detection
2. SNMP (snmpwalk with default community list) — info disclosure / weak auth
3. LDAP (ldapsearch anonymous bind) — info disclosure
4. Postgres / MySQL / MSSQL (nmap NSE auth checks) — default-credential detection
5. FTP / Telnet (anonymous-login detection) — historical legacy services

Plugin pattern

Each per-service tool becomes its own apps/<service>_enum/ directory following the standard four-file pattern (see CONTRIBUTING.md):

apps/smb_enum/
    apps.py         # AppConfig with tool_meta (phase: 6.5 or similar)
    models.py       # empty (writes to apps/core/findings/)
    scanner.py      # orchestrator
    collector.py    # invokes enum4linux/smbclient/smbmap, captures output
    analyzer.py     # parses output, builds Finding rows for: anonymous read,
                    # writable shares, exposed shares, etc.

Tool dispatch is gated on Port.service — only ports classified as smb get the SMB enum.

Out of scope for v1

• Active exploitation — checking for vulnerabilities is in scope; demonstrating exploitation is not. Keep parity with our existing posture (read-only enumeration, no shells, no payloads).
• HTTP enumeration deep dive (feroxbuster, dirb, nikto) — that's a separate issue; web vuln scanning is already covered by nuclei + web_checker
• Credential brute-forcing — separate concern; opt-in feature with strong UX consent if ever added
• Container/cloud-specific enums — Kubernetes API enum, AWS metadata service — separate issue

Difficulty

Medium-large. Each service-specific tool is ~0.5-1 day of work (collector parsing + finding generation + tests). v1 (5 services) = ~5-7 days total focused work. Good fit for someone with pen-testing background who knows the specific tools' output formats.

Reference

This issue was opened after a side-by-side comparison with Tib3rius/AutoRecon (6k stars). Per-service enumeration is AutoRecon's primary differentiator vs. running nmap alone — closing this gap is the highest-impact depth improvement available to OpenEASD.

Position: NOT v2.0 — that's LLM-triage per the design log. This is a v2.x or v3.0 candidate depending on contributor interest. Opening now as help wanted so the right person can self-select.

[ashok-kamat]

Clarification under the unauthenticated / black-box / external scope lock (decided 2026-06-01, see issue #74 which establishes this principle for any new feature):

The line "MSSQL (1433) — `nmap` mssql NSE; `impacket-mssqlclient` for auth test" in the table above is ambiguous on whether `impacket-mssqlclient` means:

• (In scope) Probe whether the MSSQL service responds to a connection attempt and announces its required auth method — purely banner-grab / handshake observation, no credentials sent
• (Out of scope) Attempt to authenticate with default / common credentials (sa:sa, sa:password, etc.) — that's credential brute-forcing and explicitly out of scope under D-008 anti-features territory

This issue intends the in-scope interpretation only. `nmap`'s built-in mssql-info and mssql-ntlm-info NSE scripts cover the protocol-handshake observation cleanly without authentication attempts and should be the primary tool for MSSQL. `impacket-mssqlclient` is therefore probably not the right tool to wrap — implementer should default to NSE for MSSQL.

Same clarification applies to LDAP (ldapsearch -x -s base for the root DSE is fine; auth attempts are not), Postgres, MySQL, and any other service where the line between "service identification" and "credential testing" gets blurry. No credential probing in v1, even with defaults.