Kioptrix nmblookup returns <00> and <20> records: interpreting service roles (and what to do next)

---

Who this is for / not for

For you if…

• You’re doing Kioptrix-style SMB/NetBIOS enumeration and your notes keep becoming “maybe-a-fileserver” soup.
• You want defensible interpretations of <00>, <20>, and the common weird cases.
• You’re trying to stay low-noise and lab-safe while still being precise.

Not for you if…

• You’re enumerating a modern environment where NetBIOS is disabled and discovery relies on other mechanisms.
• You want exploitation steps. This stays firmly in enumeration + interpretation + confirmation.

---

Decode-first: what NetBIOS suffixes actually represent

The mental model: “names + suffixes” are advertised roles

NetBIOS name service replies are basically little identity cards taped to a host’s forehead. They tell you what names a machine is willing to answer to, and the suffix (the 16th byte) hints at the “role flavor” of that name. But here’s the trap: this is an advertisement, not a completed background check.

If you’ve used Nmap, Samba tools, or Wireshark in CTF labs, you’ve already seen this pattern: the network says “I might be X,” and your job is to turn “might” into “is” (or “is not”) with one additional test.

Show me the nerdy details

NetBIOS over TCP/IP is specified in RFC 1001/1002, and the “suffix” concept is widely used by Windows networking protocols and implementations. The suffix is carried as part of the 16-byte NetBIOS name, where the last byte encodes the suffix value. In practice, tools present it as <00>, <20>, and so on.

<00> isn’t “the service”; it’s “what name is being claimed”

<00> is the one that causes the most note-taking chaos because it can show up as:

• A unique name tied to the host (often what you think of as the computer name).
• A group name tied to a workgroup or domain-like label (less personally useful, more “crowd identity”).

I’ve personally wasted a clean 30 minutes once by treating a <00> group registration like a hostname, then wondering why my next command behaved like it had stage fright. Lesson learned: the same suffix can be attached to different kinds of names.

<20> is the loudest hint for SMB file service

In many Windows and Samba-adjacent situations, <20> strongly suggests the machine is registering a name for file and printer sharing style service. It often correlates with “SMB server capability,” but it’s still not proof that you can actually negotiate SMB from your vantage point.

Think of <20> as the sign outside a shop. It says “open.” It does not guarantee the door isn’t locked, the lights aren’t off, or you aren’t standing at the wrong entrance.

Let’s be honest…

If you’ve ever written “SMB enabled” from a suffix alone, you didn’t write a note. You wrote a future argument with yourself.

---

Kioptrix reality check: why you’re seeing both <00> and <20>

Typical lab topology: Samba/Linux acting “Windows-ish”

Kioptrix-era labs love the aesthetic of old-school Windows networking, even when the host is actually Linux with Samba. That’s why you’ll often see NetBIOS broadcasts that look “Windows-like” in form, even if the underlying OS is not.

A quick trust cue: Samba’s own documentation describes nmblookup as a NetBIOS name query tool used in NetBIOS-over-TCP/IP networks. That’s exactly the behavior you’re poking with these labs.

Workgroup noise: <00> group names muddy the water

Sometimes your <00> record is a workgroup identity, not the specific host identity you hoped for. In practical terms, it means: yes, something on that IP is participating in a named group, but it doesn’t hand you a clean, unique hostname you can confidently use in follow-on commands.

Multiple interfaces and aliases: one host, many names

Labs can be quirky: multiple interfaces, NAT layers, VM snapshots, and “helpful” aliases. A single host can register multiple names, and your query method can surface more than one of them. I’ve seen a lab box register names that looked like they were typed by someone half-asleep, which felt oddly relatable.

---

Read the output like a prosecutor: three questions to answer

1) Is the <00> entry a unique name or a group name?

Your first job is classification. If the tool output indicates group vs unique, believe it. If it doesn’t, look for contextual clues:

• Group names often resemble workgroup/domain labels you’ve seen before (short, “organizational” words).
• Unique names tend to resemble a host/computer identity, even if padded or oddly formatted.

When you’re unsure, don’t force it. Treat <00> as “a name registration exists” and move on to a confirmation tool.

2) Does the <20> align with open SMB ports?

This is where you stop guessing and start correlating. If you see <20>, your next move is not poetry. It’s a quick check for SMB presence on:

• TCP 445 (direct SMB)
• TCP 139 (SMB over NetBIOS session service)

If both ports are closed from your scanning position, <20> becomes “interesting but not actionable yet.” (And if you’re troubleshooting why your scan “missed” a service, the pattern shows up in Nmap service detection false positives more often than people admit.)

3) Are you querying the right thing?

There’s a practical difference between querying “a name” versus doing a node status style query against an IP. In Samba tooling, this commonly shows up as the difference between a basic query and a query that dumps a table of names tied to that host.

In plain terms: if your output feels thin or confusing, switch to an approach that yields a host table rather than a single-answer reply.

Money Block: Evidence eligibility checklist (yes/no)

---

Confirm SMB the quiet way: minimal commands, maximum certainty

Nmap confirmation pass (service presence, not guesses)

If you want high signal with low drama, Nmap’s SMB NSE scripts are built for this moment. For example, the SMB OS discovery script is designed to attempt OS/workgroup/computer-name discovery over SMB on ports 445 or 139. That’s not a suffix hint. That’s an actual SMB conversation attempt.

My own workflow when I’m trying to stay disciplined in a lab: I do one fast scan to confirm ports, then one SMB script that forces a negotiation. If the script speaks and the target answers, your notes get to level up from “maybe” to “evidence.” (If your scan style is inconsistent, it’s worth re-grounding on Nmap -Pn vs -sn so you don’t accidentally “prove” a host is down.)

smbclient reality check (shares tell the truth)

If you can list shares, you’re done arguing with yourself. A successful share list means:

• SMB is reachable from your position.
• The target is willing to negotiate at least some level of session.
• Your <20> interpretation now has a witness statement.

Small anecdote: I once had <20> and open 445, but my share listing failed because I used the wrong target name format and accidentally asked the wrong “identity.” It looked like “SMB is broken,” but really it was my syntax doing interpretive dance. If that specific pain hits you, the two common rabbit holes are: smbclient tree connect failed and smbclient list without access.

Here’s what no one tells you…

The best NetBIOS interpretation is the one you can back with a second tool in under 60 seconds. Anything longer invites overthinking, and overthinking is just “time theft” wearing a trench coat.

Money Block: 60-second “certainty” mini calculator

---

The <00> trapdoor: host name vs workgroup vs “it’s complicated”

When <00> is the workstation/service name (unique)

If your <00> entry is a unique name, you can usually treat it as a workable identity hint. What you can safely infer:

• A host on that IP is registering a name that behaves like a machine identity.
• NetBIOS name service is reachable enough to answer queries.

What you cannot safely infer from <00> alone:

• The OS type with certainty.
• That SMB is reachable (that’s what ports/scripts are for).
• That the name maps cleanly to DNS or to a single interface.

When <00> is the workgroup/domain (group)

This is the “crowd identity.” It’s common. It’s often unhelpful for direct pivoting. But it can still guide your mental model:

• It hints at the naming environment the host participates in.
• It can explain why you see more than one name in tables and status replies.

I like to treat this as context for later, not as a foothold. In other words: I note it, then I move on to SMB negotiation and share discovery.

The “why do I see TWO <00>s?” puzzle

Here’s a short decision tree that usually resolves the mystery without hand-waving:

• Case A: One is unique, one is group. This is normal. Host identity plus workgroup identity.
• Case B: Both appear unique. Suspect aliases, multiple services registering names, or multiple interfaces.
• Case C: Output differs between query methods. Suspect you changed modes (single-name query vs status table).

If you still can’t classify them, stop trying to “solve the name.” Confirm SMB directly and treat the names as labeling artifacts until you have stronger identity data.

---

The <20> clue: what it suggests about the target’s SMB posture

<20> plus 139/445 open: likely SMB server capability

This is the clean path. You have:

• a NetBIOS registration that commonly aligns with file service identity,
• and a reachable SMB port that can carry a negotiation.

Practical implication: prioritize SMB enumeration next. In lab environments, this is often where you quickly uncover shares, misconfigurations, or credentials you can reuse ethically in-scope.

<20> but ports closed: what could be going on?

When <20> exists but 139/445 are closed (from you), you’re looking at one of these realities:

• Firewalling or filtering between your host and the target.
• Host-based restrictions that allow NetBIOS name responses but block SMB session traffic.
• Lab topology quirks where you’re querying one interface but scanning another route.

Anecdote: I’ve watched a lab VM “change personality” after a snapshot revert, where NetBIOS replies persisted but SMB ports flipped due to a service not starting. Nothing teaches humility faster than a virtual machine that wakes up grumpy.

When <20> is present but shares aren’t

This is the classic illusion: the sign says “file service,” the door says “no.” Common reasons include:

• Authentication restrictions (no guest, no null sessions).
• Signing requirements or policy constraints that block your tooling assumptions (run a fast
  SMB signing check before you spiral).
• Permission hardening that allows negotiation but denies enumeration calls.

The right posture here is calm: you don’t need to “force” shares. You just need to document which layer failed (ports, negotiation, auth, enumeration). If your tooling shifts from “can’t list” to explicit auth errors, correlate with SMBMap NT_STATUS_LOGON_FAILURE and SMBMap access denied to label the failure correctly.

---

Common mistakes that waste hours (and how to avoid them)

Mistake #1: Treating <00> and <20> as definitive service proofs

Fix: always pair suffix interpretation with a quick port/service check. A suffix is a claim; a port is a door. You need both if you want to walk through without embarrassment.

Mistake #2: Logging “domain controller” vibes from random suffix noise

Fix: only assert directory-service roles after confirming with the protocols that actually represent them (think LDAP/Kerberos/AD-specific checks). If you don’t have that evidence, write “workgroup/domain label observed” and move on.

Mistake #3: Querying the wrong address or wrong name mode

Fix: pick one consistent workflow and stick to it. If you want host tables, use the tool mode that yields host tables. If you want single answers, use the single-answer mode. Mixing them mid-stream creates fake contradictions.

Also, a quick reality check: multiple tools can disagree because they’re asking different questions. That’s not a failure. That’s you learning which question matters.

---

Don’t do this: report notes that future-you will hate

“SMB enabled” without ports, dialects, or share evidence

Replace it with something like:

• Better: “NetBIOS indicates file service registration (<20> observed). SMB ports 445/139 were checked; SMB negotiation was attempted via tooling, results recorded below.”

“Host is FILESERVER” because <20> showed up

Replace it with language that reflects uncertainty appropriately:

• Better: “<20> registration suggests SMB server capability; confirmation pending (ports and share enumeration).”

The one sentence that keeps your report defensible

Use this plug-and-play phrasing when environments are weird:

“NetBIOS name service responses indicate file service registration, but SMB conclusions are based on corroborating evidence (port reachability and SMB negotiation results), not suffixes alone.”

Money Block: Decision card (When A vs B)

---

Short Story: from suffix soup to signal

Short Story: A few years ago in a lab that looked suspiciously Kioptrix-adjacent, I saw <00> and <20> and wrote, confidently, “SMB server confirmed.” Then I tried to list shares and got nothing. I tried again. Still nothing. I changed flags. Still nothing. I started narrating my life choices to the terminal like it was a therapist.

Ten minutes later, I realized I hadn’t actually confirmed ports from my current network position. The lab had a tiny routing quirk: NetBIOS name replies reached me, SMB session traffic didn’t. The host was advertising a role, but I was standing outside the building. The fix took 30 seconds: verify reachability, then negotiate SMB with a script, then attempt shares. The lesson wasn’t “NetBIOS is useless.” The lesson was “NetBIOS is a clue you earn the right to trust.”

---

Next step: one concrete action

Run a 2-tool confirmation loop (60 seconds)

Your goal is simple: convert “NetBIOS hints” into evidence-backed statements. Here’s the loop:

1. Verify ports (139/445) are reachable from your scanning host.
2. Attempt SMB share enumeration with the lightest tool you trust.

If the loop succeeds, your note becomes: “SMB confirmed (ports reachable + share attempt evidence).”
If it fails, your note becomes: “NetBIOS suggests SMB registration; SMB not confirmed from current position (document which step failed).”

Infographic: the NetBIOS-to-SMB evidence ladder

---

FAQ

1) What does <00> mean in nmblookup results?

It’s a NetBIOS suffix attached to a registered name. In labs, it often shows a host-style name or a workgroup-style group name. The key is not the suffix alone, but whether the name is unique or group and how it correlates with other evidence (ports, SMB negotiation).

2) Does <20> always mean SMB is running?

No. It commonly suggests file service registration, but SMB reachability still depends on whether 139/445 are accessible and whether SMB negotiation succeeds from your position. Treat it as a strong clue, then confirm.

3) Why do I see multiple <00> records for the same IP?

Often because one is a unique host-style registration and another is a group/workgroup registration, or because the host has aliases or multiple registrations surfaced by different query modes. Classify unique vs group, then validate with SMB evidence.

4) What’s the difference between NetBIOS name service and SMB service?

NetBIOS name service is about name registration and resolution (who answers to which names). SMB service is the file-sharing protocol itself (negotiation, authentication, share access). Name clues help you prioritize, but SMB tests confirm reality.

5) If I see <20>, should I scan 139 and 445 next?

Yes, as a practical next step. Those ports are the most direct “is this reachable?” check that upgrades your interpretation from a hint to evidence.

6) Can Linux/Samba hosts show <00> and <20> like Windows?

Yes. Samba can participate in NetBIOS naming behavior and register names that look very Windows-ish, which is why these suffixes show up frequently in Kioptrix-style labs.

7) What should I write in a pentest report based on <00>/<20>?

Write what you can support: “NetBIOS registration indicates…” and then include the confirmation step you performed (ports, SMB negotiation, share enumeration). Avoid definitive service claims unless you actually tested the service. If you want the phrasing to match professional report expectations, align it with your reporting structure (for example, the “evidence-first” style used in how to read a penetration test report).

---

Conclusion

Let’s close the loop from the hook: <00> and <20> aren’t answers. They’re invitations. In Kioptrix-style labs, that invitation is usually worth following, but only with the discipline of one more check. If you remember nothing else, remember this: suffixes are claims; ports and negotiation are evidence.

Your next move, within the next 15 minutes: pick the one host you care about most, run the 2-tool confirmation loop, and rewrite your notes into one defensible sentence that names what you tested. Your future self will thank you, quietly, while deleting an unnecessary screenshot.

Last reviewed: 2026-MM-DD.