Kioptrix SMB signing check without CME: nmap script + manual confirmation

Mastering SMB Signing: From Scan Output to Report-Ready Precision

Most SMB scans don’t fail because the target is clever. They fail because you wrote down the wrong adjective.

If you’ve ever logged “SMB signing enabled” at 1:40 AM, then realized the real question was “Will an unsigned session still work?”, this is your fix. In Kioptrix-style labs, the difference between enabled and required is the difference between a clean note and a cleanly wrong report.

SMB signing is a message-integrity feature that lets an SMB client and server cryptographically sign requests and responses to prevent tampering.

• Enabled: Signing is available and may be used.
• Required: The server enforces it and rejects unsigned sessions.

SMB1 and SMB2/3 negotiate this differently, so one script on one port can quietly miss the truth. Here you’ll do a low-noise Nmap NSE first pass, then a manual confirmation step (SMB1 via smbclient, SMB2/3 via an SMB2-capable client or packet visibility) that turns “supported” into a defensible yes/no.

Save artifacts. Name the ports. Sleep better.

Keep reading if you want the shortest path from scan output to a report-ready sentence.

---

Who this is for / not for

For: authorized lab defenders, sanctioned pentesters, and learners on Kioptrix/VulnHub/HTB-like targets who need a fast, defensible “enabled vs required” statement without installing CME. If your environment is explicitly allowed and you’re writing notes like an adult, this workflow fits.

Not for: drive-by scanning, “curiosity” against systems you don’t own, or anything that smells like real-world targeting. SMB signing checks can be low-noise, but “low-noise” is still “a scan,” and permission is still the entry ticket. (If you need a clean policy anchor for that boundary, pin a vulnerability disclosure policy or internal rules-of-engagement note right next to your lab checklist.)

One honest confession: early in my lab days, I used to treat SMB signing like a light switch. On or off. Then I wrote “signing enabled” in a report draft and realized the stakeholder question wasn’t “enabled?” It was “Can an unsigned session work?” That’s “required.” Different question. Different consequence.

---

Scope lock: what “SMB signing” really means in practice

Signing enabled vs signing required (the only distinction that matters)

Enabled means the server can sign SMB messages and may use signing in some cases. Required means the server insists on signing; an unsigned session can’t proceed cleanly. In real pentest documentation, “required” is the line that changes feasibility for certain attack paths and relaying scenarios. “Enabled” is the line that people misread.

SMB1 vs SMB2/3 matters (your script choice changes the truth)

Kioptrix-style targets are time capsules. Some speak only SMB1, some speak SMB2+, and some do that annoying thing where port 139 behaves differently than 445. That means you can’t treat a single output line as gospel unless you know which dialect you actually negotiated. (If you want the quick mental model, see port 139 vs 445 SMB behavior in null-session-style tests and steal the “separate the ports” note-taking habit.)

Let’s be honest… “supported” ≠ “enforced”

Tools love the word “supported.” It sounds reassuring. It is also a trap. You’re hunting for “required” (enforced) versus “enabled” (optional). Everything else is garnish.

Show me the nerdy details

At a protocol level, “required” means the server’s negotiation and session setup logic expects signed messages (and will reject or fail sessions that don’t meet signing policy). SMB1 and SMB2+ represent signing in different parts of the negotiation flow, which is why script choice matters. When you see vague terms like “supported,” you’re usually looking at capability rather than enforcement.

Small lived-experience moment: I’ve seen VM templates where Samba defaults changed after an update, so the same “Kioptrix-like” box behaved differently between boots. If your result changes after a reboot, assume configuration drift before assuming you “misread” the protocol.

---

Nmap first pass: scripts that usually answer in one scan

Minimal command you can copy-paste (low noise, high signal)

Start with exactly the scripts that answer the signing question, and exactly the ports that matter:

nmap -p 139,445 --script smb-security-mode,smb2-security-mode <IP>

If host discovery is blocked in your lab setup (NAT/host-only weirdness), you can add -Pn to skip ping. Try not to add more than you need. (If you want a tight explanation for when -Pn is legitimate vs when it’s masking a routing problem, bookmark Nmap -Pn vs -sn so you stop “fixing” network reachability with bigger scans.)

• What this does: probes SMB1 security mode and SMB2+ security mode where possible
• What it avoids: broad enumeration, credential guessing, “oops I scanned the world” energy

Read the output like a prosecutor (what strings actually mean)

Different Nmap/NSE versions print slightly different phrasing, but the logic stays steady. You’re looking for language that clearly implies one of these states:

• Signing required: the server enforces signing, unsigned won’t work
• Signing enabled, not required: optional signing, unsigned may still work
• No SMB2 output: often SMB1-only or SMB2 negotiation failed

Important: if you see only SMB1 results, don’t “assume SMB2 is off.” Assume “SMB2 wasn’t negotiated.” Those are different facts.

Curiosity gap: when Nmap lies by omission

Nmap is honest, but it’s not psychic. If SMB2 scripts show nothing, it might be because SMB2 isn’t supported, or because the server refused negotiation, or because the script couldn’t complete its handshake for environmental reasons. That’s why you do the manual confirmation step: to turn “maybe” into “yes/no.”

Personal anecdote: the first time I saw “message signing enabled but not required,” I stopped. I celebrated. Then I realized I didn’t actually know if my client attempt was signed. The output told me the server’s posture, not my session’s behavior. That’s when I started always doing the second step.

---

Precision scan: force “required or not?” without extra chatter

Narrow to the exact script and port that responds

If 445 responds cleanly, start there. If it’s ambiguous, fall back to 139. The goal is to reduce variables, not collect trophies.

nmap -p 445 --script smb2-security-mode <IP>
nmap -p 139 --script smb-security-mode <IP>

If one script produces output and the other doesn’t, that’s not a failure. It’s a clue about dialect support and how the service is exposed.

Add version context (only if needed)

If you need service context for reporting (again, in a lab), add service detection. Keep it disciplined:

nmap -p 139,445 -sV --script smb-security-mode,smb2-security-mode <IP>

In my notes, I treat -sV like hot sauce: helpful in small amounts, regrettable when poured over everything. (If you’re tired of getting “confidently wrong” banners, see how -sV produces false positives and why saving raw output beats trusting your memory.)

Why Kioptrix-like images sometimes flip signing between boots

Some lab images have startup scripts, template resets, or package differences across snapshots that quietly change Samba defaults. If your result changes, record the VM snapshot, date/time, and any updates you applied. Your “evidence trail” matters even in a personal lab, because it trains you for real client work. (For a repeatable “don’t lose the receipts” workflow, copy the structure from Kali lab logging and standardize filenames per target.)

Show me the nerdy details

Nmap NSE scripts depend on completing specific negotiation steps. If a target only supports SMB1, SMB2 scripts may not run. If the target supports SMB2 but blocks certain negotiation features, the script may fail silently or return partial information. Precision scanning reduces “tool noise,” making it easier to spot which layer is failing: reachability, port exposure, dialect negotiation, or policy enforcement.

One more lived-experience note: if you’re scanning a VM behind a host-only adapter and your results look “filtered,” don’t panic and expand the scan. Fix the network path first. A clean, small scan on the right interface beats a big scan on the wrong one.

---

Manual confirmation path A: SMB1 check with smbclient (quick sanity)

One-shot negotiation test (what to observe)

For SMB1-oriented targets, smbclient can be a quick sanity probe. Keep it read-only and minimal. In a lab, a common first attempt is:

smbclient -L //<IP> -N

This asks for a share list with no credentials (-N). The point isn’t to “get in.” The point is to see if the server negotiates and how it behaves. If you’re allowed to increase visibility, run with verbose output so you can observe negotiation hints:

smbclient -L //<IP> -N -d 3

• Good sign for your analysis: you can see negotiation progress and any signing-related hints in debug output
• Bad sign for your sleep: you get a generic failure that could mean five different things unless you log details

Increase visibility without increasing risk

Verbosity is your friend. Credential spraying is not. You’re looking for protocol-level behavior, not “try 50 passwords and hope.” If you’re documenting a lab exercise, capture the exact command and the first 30–60 lines of output that show the negotiation path. (If you hit that classic “it lists something but I still can’t access anything” moment, it pairs well with smbclient list works but access still fails.)

Here’s what no one tells you…

A successful anonymous list does not prove signing isn’t required. It only proves your session met the server’s rules. If your client used signing automatically (or if the server didn’t require it for that flow), you still haven’t answered the enforcement question. That’s why Path B exists: it focuses on enforcement signals.

Show me the nerdy details

SMB clients may opportunistically use signing depending on configuration and server capabilities. That means an SMBclient success can occur even when signing is required, because the client complied. Manual confirmation becomes meaningful when you can compare behavior under conditions that differ by signing (or at least observe explicit “signing required” negotiation errors in verbose logs).

Personal anecdote: I once spent 30 minutes chasing “permissions” because I saw “access denied,” when the real issue was a negotiation policy mismatch. The error message was technically true, just not useful. Verbose logs saved the day, and my pride did not survive. (If you want a clean “is this auth vs protocol vs policy?” checkpoint, the same mindset shows up in rpcclient NT_STATUS_ACCESS_DENIED triage.)

---

Manual confirmation path B: SMB2/3 check without CME (verify enforcement)

Use an SMB2-capable tool to confirm “required”

Your manual confirmation goal is simple: determine whether the server enforces signing for SMB2/3 sessions. Many environments use tools like Wireshark for visibility and SMB2-capable clients for negotiation. If you have an SMB2-capable client in your toolkit, run a single, minimal connection attempt with verbose logging enabled.

What you’re validating:

• Signed negotiation allowed: the server proceeds when signing is present
• Unsigned negotiation refused (or fails early): strong evidence signing is required

In other words: you’re not trying to “do something” to the box. You’re trying to watch the box refuse to talk unless the rules are followed.

Validate by failure mode (the safest proof)

The safest proof is often a controlled failure. If your tooling lets you adjust signing behavior (or at minimum surfaces a clear negotiation error), you can document the difference between a generic auth failure and a signing enforcement failure.

Operator mindset: “Access denied” is about who you are. “Signing required” is about how you speak.

The “required” tell that hides inside generic failures

Some tools compress negotiation errors into a bland “NT_STATUS_*” output. That doesn’t mean the signal isn’t there. It means you need to turn on verbose logs or use packet capture to see the negotiation flags. Microsoft’s SMB behavior and policy controls are well documented in Windows security settings and SMB signing guidance, and Samba’s configuration options are described in Samba documentation. In labs, Wireshark is often the simplest truth serum when tool output is coy.

Show me the nerdy details

Packet capture can show whether SMB2 session setup messages are signed and whether the server advertises or enforces signing. Even if your client tooling doesn’t present a “signing required” banner, the negotiation flow often reveals it. The key is to keep the test minimal: one connection attempt, one capture, one conclusion.

Quick lived-experience moment: on one lab box, 445 showed what looked like “enabled,” but 139 behaved differently. If I’d stopped at the first scan, I would’ve written a clean sentence that was cleanly wrong. Testing both ports felt boring. It also kept me honest.

---

Edge cases that fool people on Kioptrix

SMB on 139 only (NetBIOS) vs 445 direct-hosted

Some older images are weirdly polite on one port and stubborn on the other. If you get ambiguity, test both ports with the same discipline. Do not “average” results in your head. Record them separately.

Guest access and “false comfort”

Guest access can make everything feel like it’s working, which tempts you to conclude “no signing enforcement.” That’s a logic error. Guest is about authentication. Signing is about transport policy. Keep them in separate mental drawers.

SMB dialect mismatch (SMB1-only boxes)

If your SMB2 script returns nothing, don’t force it into meaning. Treat it as a signal: you may be talking to an SMB1-only service or the environment isn’t allowing SMB2 negotiation. Either way, document what you attempted.

Show me the nerdy details

Different SMB transports and dialects can present different security mode capabilities. Older stacks may default to SMB1 behaviors on 139, while 445 might expose direct-hosted SMB with different negotiation results. Testing both is a practical way to avoid false certainty.

Short Story: I once ran a lab scan after a long day and got a beautiful “enabled but not required” line. I wrote it down like it was scripture. The next morning, with coffee and less ego, I rechecked on port 139. Different behavior. I rechecked with a minimal manual connection and verbose logs. It turned out my first result wasn’t “wrong,” it was “incomplete.”

The box was effectively SMB1-first, and my tool output had been overly tidy. The lesson wasn’t “never trust tools.” The lesson was “trust tools the way you trust a flashlight: it shows what you point it at.” Once I treated the process like evidence collection instead of fortune-telling, the lab stopped feeling like a carnival game. (120–180 words) …

---

Common mistakes (loss-prevention)

Mistake #1: Treating “enabled” as “required”

This is the classic report bruise. “Enabled” means signing is available. “Required” means unsigned doesn’t work. If you mix these up, you don’t just make a small error, you mislead downstream decisions.

Mistake #2: Running only one script and calling it done

If you only check SMB2 on a box that’s SMB1-only, you’ll get silence and invent meaning. If you only check SMB1 on a box that’s SMB2+, you might miss enforcement. Use both scripts unless you can justify why one isn’t applicable.

Mistake #3: Scanning the wrong interface/segment in lab NAT setups

Filtered ports in a VM lab often mean “you’re not actually reaching it,” not “the service is hardened.” This is where people expand scans, increase timing aggressiveness, and add more scripts. That’s how you waste an hour. Fix routing first.

Personal anecdote: my worst lab nights were the ones where I didn’t save outputs. Not because I couldn’t redo the scan, but because I couldn’t explain the “why” later. Screenshots and logs feel boring until they feel like rescue. (If you want a frictionless system for “proof without chaos,” pair your SMB notes folder with a screenshot naming pattern that stays OSCP-friendly.)

---

Reporting-ready interpretation: write the finding in one clean sentence

This is where you make your future self proud. Use language that separates ports and avoids assumptions about dialects you didn’t negotiate.

If signing is required

“SMB signing is required on port(s) 445/139; unsigned sessions are not accepted.”

If signing is enabled but not required

“SMB signing is enabled but not required; the server permits unsigned sessions.”

If inconclusive

“SMB signing status could not be confirmed due to dialect/port limitations; SMB1/SMB2 checks returned ambiguous negotiation output.”

Show me the nerdy details

Report language should reflect the strongest supported claim. If your scan indicates “enabled,” don’t upgrade that to “required.” If your manual confirmation proves enforcement via negotiation failure (or explicit signing-required signals), then “required” is appropriate. When in doubt, “not confirmed” is more professional than accidental certainty.

Commercial entity signals, kept neutral and accurate: you’re using Nmap NSE scripts for the first pass, potentially Samba tooling for SMB client negotiation, and often Wireshark for packet-level visibility. If your target is Windows-based, Microsoft’s SMB signing policies and security settings shape what “required” means in practice. All of these are legitimate, defensible tools to mention in a report without turning into a product pitch. (If you want your “one clean sentence” to sit inside a consistent findings structure, see how to read a penetration test report and mirror the language patterns that stakeholders actually understand.)

---

FAQ

---

Conclusion: next step in 15 minutes

Let’s close the curiosity loop from the hook: you now have a way to stop arguing with the word “supported” and start answering the real question, “Is signing required?” Nmap gives you the fast first pass. Manual confirmation turns it into a defensible finding. The win isn’t sophistication. The win is repeatability.

One infographic: the “Enabled vs Required” decision flow

Run a 2-step check and save outputs (the 15-minute version)

1. Run Nmap with smb-security-mode + smb2-security-mode against -p 139,445 and save stdout.
2. Perform one manual negotiation attempt with verbose logging and attach both artifacts to your notes.

Last reviewed: 2026-03-02

Lab-only reminder: keep scans minimal, avoid credential guessing, and treat outputs as sensitive assessment data. If you want a quick upgrade next, add one packet capture on the manual step so your “required vs enabled” conclusion has both tool output and observable negotiation behavior in the same evidence bundle. (And when you’re ready to turn lab notes into a real deliverable, drop this finding into a consistent structure like a pentest report template so your evidence and your sentence stay welded together.)