Reviewed October 21, 2026. Commands are examples for an authorized, isolated lab; no target results are asserted here.
A hostname without a share list is an expected nbtscan result. The tool requests NetBIOS name information. It does not perform SMB share enumeration. Before changing credentials or protocol settings, check whether a separate SMB command has actually asked for shares.
Names and shares come from different operations
| Observation | What it tells you | What it does not tell you |
|---|---|---|
| nbtscan returned a computer name | A NetBIOS node-status reply was received. | Whether an SMB session or share connection will succeed |
| nbtscan returned a group label | The reply included that registered name. | AD membership, credentials or administrator privileges |
| No nbtscan reply arrived | No response was observed for that query. | Whether direct SMB on TCP 445 is available |
| A separate share-list request was denied | That request failed under its particular session context. | Whether no shares exist, or a known share would accept a permitted connection |
Use the installed nbtscan syntax
There are different packages with similar names. These examples are for Kali’s nbtscan, not nbtscan-unixwiz. Read the installed help before borrowing flags between them. Replace TARGET_IP with the address of the verified lab VM.
nbtscan --help
nbtscan TARGET_IP
# Optional: show all returned names for that one address
nbtscan -v TARGET_IPIn this nbtscan implementation, -h is a human-readable service-name option used with verbose output; it is not the help flag. Keep the query to the assigned target rather than copying an example that scans an entire subnet.
Retain the address, time, name rows and flags. Treat names and any MAC field as returned metadata. They may be missing, stale or insufficient to identify the VM; compare your hypervisor or lab address inventory separately. To interpret suffixes such as <00> and <20>, use the NetBIOS name-table guide.
If the exercise requires share enumeration
First use the port observations from your authorized service discovery. A UDP name-service reply does not prove that TCP 139 or 445 is reachable. Conversely, a silent name-service query does not rule out an SMB service that does not use NetBIOS discovery.
For a permitted share-list request, replace SMB_PORT with the observed SMB port and use the assigned lab identity:
smbclient -L TARGET_IP -p SMB_PORT -U 'WORKGROUP/labuser'Let the client prompt for the password. This is a new operation with its own result; it does not “complete” nbtscan output. If it fails, keep the full line and classify it as transport, negotiation, session setup or a later enumeration error. Do not describe every ACCESS_DENIED as a wrong password or proof that shares exist.
A returned share name still does not establish file access. A known share from the exercise documentation can be tested separately if authorized, even when general share enumeration is restricted. Use the exact published share name, not a guessed server filesystem path. See share listing versus directory access.
Find the next missing observation
This selector routes a symptom to a check. It does not diagnose your target, run a command or score its security.
Select the observed symptom, then show its next check.
Write a note that survives contradictory results
Illustrative note: “At T1, nbtscan returned the name LABHOST for the assigned address. At T2, a separate SMB session setup request was rejected for the assigned account. Share names and file permissions remain unconfirmed.” This records two observations without inventing a common cause. Replace the example with your actual commands, timestamps and errors.
If the address or VM state changed between checks, repeat only the smallest necessary observation after confirming the target. Do not infer a protocol problem from an old hostname response or start credential guessing to fill an empty result.
Primary reference: Kali’s nbtscan usage and options. Continue with the SMB stage checklist and operation record for a structured comparison.