Old Kit, New Kit Part 7: SMB Enumeration — NetExec vs Enum4linux and Smbclient

This is the sixth tool-pair actually run in a series testing classic, well-documented Kali tooling against its quieter modern replacements, with a genuine look at what a lab Wazuh deployment sees from each. SMB enumeration: netexec against enum4linux and smbclient, run for real against target-metasploitable2 (an ancient, wide-open Samba 3.0.20 install) and target-win2022 (a hardened, non-domain-joined Windows Server 2022 host). This is also the first pair in the series to hit a Windows target with a Wazuh agent enrolled, so the detection section below is a genuinely different kind of alert than the Apache-access-log rules from Parts 5 and 6.

How this was verified

nxc (NetExec) was already installed. Classic-side tooling turned out to need a quick check first — Kali1 has the original Perl enum4linux (v0.9.1) but not its modern Python rewrite, enum4linux-ng:

$ which enum4linux enum4linux-ng smbclient
/usr/bin/enum4linux
enum4linux-ng not found
/usr/bin/smbclient

SMB ports were confirmed open first: metasploitable2 has both 139 and 445 open (Samba smbd 3.X - 4.X, workgroup WORKGROUP, already known from Part 2’s full scan); target-win2022 only answers on 445, with 139 filtered and its service version unconfirmed by plain nmap.

The classic baseline: enum4linux and smbclient

The first timed run against metasploitable2 came back at 83.74 seconds — badly inflated, and worth explaining rather than quoting at face value. enum4linux’s password-policy check shells out to rpcclient without suppressing an interactive prompt, and it sat there waiting on a Password: prompt in the middle of what’s supposed to be a fully unattended null-session enumeration. Re-running with stdin redirected from /dev/null (so the prompt gets an immediate EOF instead of blocking) gave a clean, reproducible number: 10.11s and 10.15s on repeat runs.

That one command pulled a genuinely comprehensive haul from metasploitable2 with zero credentials: a full account list via RID cycling (33 real usernames — root, msfadmin, postgres, mysql, ftp, distccd, tomcat55, sshd, and more), the share list (print$, a world-writable tmp share with the comment “oh noes!”, opt, IPC$, ADMIN$), an OS fingerprint (Samba 3.0.20-Debian), the domain SID, and the password policy (minimum length 5, complexity disabled, no history enforced). smbclient’s own share listing matched exactly, in 0.13 seconds.

Against target-win2022, both tools failed completely rather than slowly:

$ time enum4linux -a 10.10.10.50 </dev/null
[E] Can't find workgroup/domain
No reply from 10.10.10.50
[E] Server doesn't allow session using username '', password ''.  Aborting remainder of tests.
real    20.28s

$ time smbclient -L //10.10.10.50/ -N
session setup failed: NT_STATUS_ACCESS_DENIED
real    0.06s

That’s not a performance gap, it’s a structural one. Both tools are built entirely around legacy NetBIOS name resolution and null-session SMB tricks, and a hardened, modern Windows Server 2022 box simply refuses both outright by default.

The modern tool: netexec

netexec’s plain nxc smb <target> invocation — no credentials, no session, just SMB protocol negotiation — is where this pair’s real story is:

$ time nxc smb 10.10.10.20
SMB   10.10.10.20   445   METASPLOITABLE   [*] Unix (name:METASPLOITABLE) (domain:localdomain) (signing:False) (SMBv1:True) (Null Auth:True)
real    5.85s

$ time nxc smb 10.10.10.50
SMB   10.10.10.50   445   TARGET-WIN2022   [*] Windows Server 2022 Build 20348 (name:TARGET-WIN2022) (domain:target-win2022) (signing:False) (SMBv1:None)
real    9.08s

Against target-win2022 — the host that gave enum4linux and smbclient absolutely nothing — netexec pulled the hostname, the exact OS build (Windows Server 2022 Build 20348), and SMB signing status, entirely from protocol negotiation, which every SMB server has to answer before any session or credentials come into play. signing:False is itself a genuine, actionable finding: SMB signing isn’t enforced on this host, which puts NTLM relay squarely on the table. This isn’t netexec being faster than the classic tools on the same job — it’s a job the classic tools structurally cannot do at all against a hardened target.

--shares and --users filled out the rest of the picture. Against metasploitable2, --shares (4.21s) matched enum4linux’s share list exactly, with the added benefit of explicit READ,WRITE permission annotations per share rather than a separate map-and-guess step. Against target-win2022, --shares (9.13s) and --users (39.06s) both failed cleanly with STATUS_ACCESS_DENIED — a well-behaved failure rather than a hang, though the --users failure took markedly longer to give up than --shares did.

The one place netexec came up short against metasploitable2 was --users: it came back completely empty, no accounts at all, because the target’s SAMR EnumDomainUsers call is restricted even under a null session — and netexec’s default user-enumeration module has no fallback for that. netexec does have its own RID-cycling feature built specifically to work around exactly this kind of restriction, so it’s worth testing head-to-head against enum4linux’s approach rather than calling this a settled loss:

$ time nxc smb 10.10.10.20 -u '' -p '' --rid-brute
[-] RPC lookup failed: RPC method not implemented
real    4.04s

It failed outright — a genuine counter-finding to how the rest of this pair reads. enum4linux’s RID-cycling code dates from an era when Samba 3.x was current and still works against it perfectly; netexec’s modern, Impacket-based RID-brute implementation calls an RPC method this vintage Samba install simply doesn’t support. Against a legacy target, the classic tool’s user-enumeration technique is the one that still works.

What Wazuh actually saw

target-win2022 is the first Windows host with a Wazuh agent to appear in this series, so this section is a genuinely different detection surface — Windows Security Event Log auditing via the agent’s event-channel collection, not the Apache-access-log rules from Parts 5 and 6. It’s also the first target in the series that’s never been touched by any earlier part, so there was no historical alert noise to filter out — a plain grep for the agent name was enough:

ssh -i ~/.ssh/wazuh-lab anon@10.10.10.10 "sudo grep -A5 '(target-win2022)' /var/ossec/logs/alerts/alerts.log | grep -oP '(?<=Rule: )\d+ \(level \d+\) -> .[^\x27]+' | sort | uniq -c | sort -rn"

Most of what came back was unrelated to any of the four tools: 255+94+6+2+1 hits under “CIS Microsoft Windows Server 2022 Benchmark” (rules 19007/19008) are Wazuh’s own scheduled compliance-scan module running on its own timetable, plus routine agent-lifecycle and service-state noise. Two things tie directly and countably to our actual commands, though. Four “Logon Failure - Unknown user or bad password” alerts (rule 60122) line up exactly with the four blank-credential SMB attempts that got denied — enum4linux, smbclient, netexec --shares, netexec --users. And five “Successful Remote Logon Detected - User:\ANONYMOUS LOGON… NTLM authentication, possible pass-the-hash attack” alerts (rule 92652/92657) are Wazuh flagging our null-session SMB negotiations under a heuristic that treats any anonymous NTLM logon as a potential pass-the-hash indicator — which is a reasonable default assumption, even though nothing here was an actual pass-the-hash attempt. One variant of that rule even appended “Possible RDP connection. Verify that KALI1 is allowed to perform RDP connections” — a canned message left over from a more generic rule template that doesn’t actually match what happened, since none of this was RDP traffic. Worth remembering that an alert’s rule number and structured fields are trustworthy; its prose description sometimes isn’t.

Two more hits, flagged under User:\Administrator with the same “possible pass-the-hash” wording, looked at first like they might implicate one of the four tools in an actual credentialed logon. Pulling the full alert bodies ruled that out:

2026 Aug 29 14:40:09 (target-win2022) ...
Rule: 92652 (level 6) -> 'Successful Remote Logon Detected - User:\Administrator - NTLM authentication, possible pass-the-hash attack.'
...Source Network Address: 10.10.10.5...

Both are timestamped hours before this test session began (14:40:09 and 15:37:41, versus testing that started around 19:31) — real, but unrelated pre-existing administrative activity from Kali1, not attributable to enum4linux, smbclient, or netexec. One incidental oddity turned up while checking: the Windows Event Log timestamp embedded inside those same alerts reads a full calendar month earlier than the Wazuh alert’s own outer timestamp for the same event — a clock-skew quirk on target-win2022 worth a one-line mention, though not something today’s testing caused or that needs chasing further here.

The detection-layer conclusion for this pair is a clean one: for null-session SMB activity, Wazuh’s Windows ruleset keys off the authentication protocol and its outcome — anonymous NTLM logon, logon failure — not which of the three tools produced it. enum4linux, smbclient, and netexec generated textually indistinguishable alerts on this target. Unlike Part 4’s User-Agent difference or Part 6’s UA-rotation story, tool choice makes zero difference to what Wazuh sees here, because the detection sits one layer below the tool, at the SMB/NTLM authentication protocol itself.

Verdict

This pair is a genuine split decision, which is itself the finding worth taking away. Against a hardened, modern Windows target, netexec did something enum4linux and smbclient structurally cannot: pull a real OS fingerprint and a concrete security misconfiguration (no SMB signing) from protocol negotiation alone, with zero credentials and zero valid session. That’s not a speed advantage, it’s a different category of capability. But against the old Samba box, enum4linux’s legacy RID-cycling trick for bypassing a restricted EnumDomainUsers call still works, and netexec’s modern equivalent doesn’t — a real case of the classic tool doing something the modern one currently can’t, against the kind of vintage target it was actually written for. On detection, this pair introduced a new surface for the series (Windows Security auditing via the Wazuh agent) and showed something Parts 4 and 6 didn’t: when the signal is the authentication protocol itself rather than an HTTP request shape, tool choice stops mattering to the SIEM entirely.