SMB Signing not required

Tenable plugin 57608 is not a software bug so much as a trust-setting problem: the remote SMB server will accept sessions where SMB signing is not required. That matters because unsigned SMB is relay-friendly; an attacker can tamper with or relay authentication traffic instead of being forced to prove message integrity. In practice this affects Windows and Windows Server systems where inbound RequireSecuritySignature is 0, plus Samba and many NAS appliances where server signing is not set to mandatory or equivalent. Newer Microsoft defaults reduce exposure on fresh Windows 11 24H2 and Windows Server 2025 builds, while domain controllers have long required signing by default.

Tenable's MEDIUM label is technically fair in the abstract but operationally inflated for enterprise prioritization. The plugin description says 'unauthenticated, remote attacker,' but the real attack path usually requires internal network position or on-path access, a coerced or poisoned NTLM authentication event, and a target that both allows unsigned SMB and receives a relayed identity with useful privileges. That combination makes this a classic post-initial-access amplifier, not a clean external foothold, so it scores lower than the vendor baseline even though the downstream blast radius can be ugly in flat networks.

Why this verdict

• Requires prior foothold or on-path access: the attacker usually needs internal network reachability, name-resolution poisoning, or coercion capability before SMB signing weakness becomes usable.
• The reachable population is narrower than the CVSS implies: domain controllers already require signing, and newer Microsoft defaults in Windows 11 24H2 / Server 2025 reduce prevalence on modern builds.
• Impact depends on a second success condition: even after a successful relay, the relayed identity still needs useful privileges on the target before this becomes meaningful lateral movement.

Why not higher?

It is not higher because the chain is conditional at multiple points: internal position, relayable NTLM traffic, a server that accepts unsigned SMB, and a privileged relayed identity. Break any one of those and the attack dies. That is too much real-world friction for a HIGH or CRITICAL patching signal.

Why not lower?

It is not IGNORE because relay tooling is mature, common, and still productive in flat enterprise networks and legacy NAS estates. If you are cleaning up AD-adjacent hardening debt, this setting is a real weakness worth fixing; it just should not outrank remotely exploitable pre-auth bugs.

1. Require SMB signing on servers — Set Windows inbound RequireSecuritySignature=1 or the Samba/NAS equivalent so ntlmrelayx-style SMB relay fails at the protocol layer. For a LOW verdict there is no SLA; treat this as backlog hygiene and roll it out during normal hardening cycles, starting with file servers, management jump hosts, and any host reachable across user VLANs.
2. Audit compatibility before enforcement — Use Microsoft SMB signing audit events and pilot GPOs to find legacy clients, NAS devices, and third-party SMB stacks that will break when signing becomes mandatory. For a LOW verdict there is no SLA; do this as part of your baseline modernization work rather than emergency response.
3. Reduce NTLM relay opportunities — Disable LLMNR/NBNS/WPAD where possible, prefer Kerberos, and tighten NTLM usage so attackers struggle to obtain relayable authentications in the first place. For a LOW verdict there is no SLA; prioritize high-value internal segments and admin workstations first.
4. Use EPA or SMB encryption where supported — Microsoft explicitly calls out SMB Server EPA and globally enforced SMB encryption as protective against this class of relay attack. For a LOW verdict there is no SLA; apply during platform refreshes and to sensitive file services first.

Run this from an auditor workstation or jump box that can reach the target over TCP/445; it does not need admin rights on the remote host, but it does require nmap with the smb2-security-mode NSE script installed. Invoke it exactly as ./check-smb-signing.sh 10.0.0.25 or ./check-smb-signing.sh fileserver.example.com.

#!/usr/bin/env bash
# check-smb-signing.sh
# Exit codes:
#   0 = PATCHED (SMB signing required)
#   1 = VULNERABLE (SMB signing enabled but not required, or disabled)
#   2 = UNKNOWN (host unreachable, nmap missing, parse failure)

set -u

TARGET="${1:-}"

if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <ip-or-hostname>"
  echo "UNKNOWN"
  exit 2
fi

if ! command -v nmap >/dev/null 2>&1; then
  echo "nmap not found in PATH"
  echo "UNKNOWN"
  exit 2
fi

OUT="$(nmap -Pn -n -p 445 --script smb2-security-mode "$TARGET" 2>/dev/null)"
RC=$?
if [[ $RC -ne 0 || -z "$OUT" ]]; then
  echo "nmap scan failed or returned no output"
  echo "UNKNOWN"
  exit 2
fi

# If 445 is closed/filtered, we cannot determine signing state.
if echo "$OUT" | grep -Eiq '445/tcp\s+closed|445/tcp\s+filtered|445/tcp\s+host-unreach|0 hosts up'; then
  echo "SMB port 445 not reachable"
  echo "UNKNOWN"
  exit 2
fi

# Nmap NSE commonly reports one of these strings.
if echo "$OUT" | grep -Fqi 'Message signing enabled but required'; then
  echo "PATCHED"
  exit 0
fi

if echo "$OUT" | grep -Fqi 'Message signing enabled but not required'; then
  echo "VULNERABLE"
  exit 1
fi

if echo "$OUT" | grep -Fqi 'Message signing disabled'; then
  echo "VULNERABLE"
  exit 1
fi

# Fallback: if script output is missing but SMB is open, verdict is uncertain.
echo "Could not confidently parse SMB signing state"
echo "UNKNOWN"
exit 2

Sources

1. Tenable Nessus Plugin 57608
2. Microsoft Learn - What is Server Message Block signing?
3. Microsoft Learn - Control SMB signing behavior
4. Microsoft Learn - SMB security hardening
5. Microsoft Support - SMB Server hardening audit support
6. Samba documentation - smb.conf / server signing
7. MITRE ATT&CK - Impacket (S0357)
8. CISA Known Exploited Vulnerabilities Catalog