The NETBIOS bias

Have you heard of NETBIOS?

When a hacker spots a system with open ports supporting NetBios, the hopes go high!

But, why so? In order to understand, let's do a deep dive in NETBIOS!

It's a really old concept (especially in this world of Cloud), so let's begin by going back in time!

The NetBIOS interface was developed for IBM in 1983. This operated over proprietary protocols on IBM’s PC Network which is a broadband local area network.

The broadband PC Network is a bus attached LAN, which can accommodate up to 72 connecting devices.

It is important to note the scale of LAN, NetBIOS was not designed for large networks.

• Then came the token ring by IBM [NetBEUI]. The Token-Ring network can accommodate up to 260 devices on one ring and multiple rings can be connected by Bridges.

• In 1986 Novell released Advanced NetWare version 2.0 based on NetBIOS encapsulated in IPX/SPX.

• Later Microsoft provided encapsulation of NetBIOS in IPX/SPX that is compatible with the Novell implementation.

• With the Personal System /2 computer (PS/2) in 1987, IBM announced the PC LAN Support Program which included a NetBIOS driver.

So, companies kept building over the protocol, tweaking it to support different purposes. It was around that time, in March 1987, when RFC 1001 was published which described a "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport".

Check it out here: RFC 1001

(RFC 1002 too if you want to obsess over it)

It stated

Protocols supporting NetBIOS services have been constructed on diverse protocol and hardware foundations. Even when the same foundation is used, different implementations may not be able to interoperate unless they use a common protocol. To allow NetBIOS interoperation in the Internet, this RFC defines a standard protocol to support NetBIOS services using TCP and UDP.

This line is important:

This protocol is not routable and hence scalable on it's own. But it can become so by relying on underlying TCP/IP stack for that.

Leading to NetBios over TCP/IP [NBT] protocol.

Okay, did I just use the term protocol? Hmm, suddenly I am having this urge to fit this in the OSI layers! So where would NetBios fit in in the OSI layer?

Here:

NETBIOS occurs at the session layer, Layer 5!

What is SMB? Keep your curiosity high, I'll cover it in some post soon, but if you can't wait and wondering how it differs from NetBIOS, check out this amazing description by the person on StackOverflow: Link

---

NetBIOS provides three distinct services:

• Name service (NetBIOS-NS) for name registration and resolution.

• Datagram distribution service (NetBIOS-DGM) for connectionless communication.

• Session service (NetBIOS-SSN) for connection-oriented communication.

Name service

In order to start sessions or distribute datagrams, an application must register its NetBIOS name using the name service. In NBT, the name service operates on UDP port 137 (TCP port 137 can also be used, but rarely is).

The name service primitives offered by NetBIOS include adding a name, group name, delete, and find a name.

Note that: NetBIOS name resolution is not supported by Microsoft for IPv6.

Datagram distribution service

Datagram mode is connectionless, the application is responsible for error detection and recovery. In NBT, the datagram service runs on UDP port 138.

The datagram service primitives offered by NetBIOS include sending datagram (unicast/broadcast), receiving datagram (wait for a packet to arrive from unicast/broadcast sent operation)

Session service

Session mode lets two computers establish a connection, allows messages to span multiple packets, and provides error detection and recovery. In NBT, the session service runs on TCP port 139.

The session service primitives offered by NetBIOS include Call, Listen, Hangup, Send, Send No Ack, Receive

Do you see, when you just want to detect NETBIOS, three different ports are being utilized as stated above!

---

That's cool, but why would one's eyes shine if one happens to spot this port open?

Well, well because, the NetBIOS service can be an easy target as it is simple to exploit and runs on Windows systems even when not in use. NetBIOS enumeration allows attackers to read or write to a remote computer system (depending on the availability of shares) or launch a denial of service (DoS) attack.

One can enumerate NETBIOS on a remote host by using nbtstat Windows utility

Nbstat is a utility that displays protocol statistics and current TCP/IP connections using NBT (NetBIOS over TCP/IP), which helps troubleshoot NetBIOS name resolution issues. Normally, name resolution is performed when NetBIOS over TCP/IP is functioning correctly. It does this through a local cache lookup, WINS or DNS server query or through LMHOSTS or hosts file lookup.

Look at the name, WINDOWS10 <00>

What is that character <00> at the end?

That is a typical NETBIOS service suffix code.

The NetBIOS namespace is flat and uses sixteen

alphanumeric characters. Only 15 characters are available as the last letter is

reserved for service type:

But wait, what if you do not have Windows installed? Is there still a way to do NETBIOS enumeration?

YES! Especially, if you have been following NMAP (checkout my previous blog post), there is good news!

You can also use nmap to do NETBIOS Enumeration!

Check this out:

>nmap -sV -v --script nbstat.nse [Target IP Address]

Nmap provides this script nbstat.nse that can help us do the same from Linux!

So, what are you waiting for? Go, TRY IT OUT yourself! And let me know how you find it.

To stay updated with more posts on hacking and cybersecurity, subscribe aditi.fyi, the YouTube Channel and join our Discord Community!

Keep Hacking!