Home > Articles > Operating Systems, Server > Microsoft Servers

NetBIOS and SMB-Based Networking5 in Windows NT

The chief focus of this section is the SMB protocol implemented in Windows NT (and the vulnerabilities it presents), although the NetBIOS protocol deservedly gets some of the attention. The Common Internet File System (CIFS), which implements the application and presentation layers of the OSI model, is Microsoft's implementation of SMB (a draft standard proposed by Microsoft and several other companies).

Introduction to SMB

SMB packets can be up to 65536 bytes in length, not counting an optional field in the header that indicates how long the packet is. SMB communicates directly with the NetBIOS layer, but it also works in conjunction with lower-layer protocols. At the transport layer, for example, it adds 4 bytes of data concerning transport handling initially transmitted with the TCP stream. SMB itself cannot determine which particular TCP packets are part of each individual session that has been established, so it turns over to TCP the responsibility of actually segregating the sessions. SMB can also, however, work in connection with UDP. In this case SMB sends 12 bytes of filler data to help the receiving system put the packets back in their intended sequence.

SMB also has a built-in mechanism that allows a system to transmit multiple requests within the same session. This allows sending requests in parallel rather than serially. The name of this mechanism is AndX; it is a legacy mechanism from earlier days of networking resulting in part from the need to increase the efficiency of connections.

Structure of SMB Packets

Let's look at the structure of the SMB packet. Associated with each offset is a field that carries designated types of data. Table 3.1 lists each offset, field name, and field length in bytes.

  • Note that the first offset contains the optional 4-byte length integer field mentioned previously.

  • The header start, a mandatory field, starts at offset 4 and is also 4 bytes in length.

  • The SMB command field, 1 byte long, is used to communicate to the receiving system that the packet contains a particular SMB command used in a es the "Key" communication.

  • The smb_rcls and smb_err fields, both 2 bytes in length, begin at offsets 9 and 11, respectively. These fields, used to transmit, indicate when something goes wrong in these communications and what the nature of the error condition is.

  • The 1-byte smb_flg and 2-byte smb_flg2 fields, beginning at offsets 13 and 14, respectively, are fields used to set flags that indicate the status of the communication between SMB-capable hosts.

  • The next field beginning at offset 16 is reserved for data in TCP and UDP information that indicates the sequence of packets.

  • The TID ("Tree ID") field (starting at offset 28) is for the 2-byte tree ID, a value used for the "tree connect" mechanism that indicates exactly where in the file system on a host to connect when a session that allows such a connection has been established.

  • The PID ("Process ID") field (2 bytes long, starting at offset 30) indicates the process ID of the process associated with the network application on the machine sending the packet.

  • The UID is an arbitrary user ID (unrelated to the NT logon ID); this field begins at offset 32 and is also 2 bytes long.

  • The MID (2 bytes long, beginning at offset 34) is for the machine ID.

  • Offset 36 is the beginning point for the 1-byte parameter word count, a field that tells the receiving system how many of the subsequent smb_vwv fields will follow. These smb_vwv fields contain data used in parsing the data that follow in the variable-length buffers.

Table 3.1 The Structure of the SMB Packet



Number of Bytes


Length integer (optional)



Header start



SMB command






























Parameter word count














Relationship with the NetBIOS Layer

Networked clients and servers need to how to communicate with each other. They frequently need, for example, to know each other's IP address and computer name. In conventional TCP/IP-based networking, DNS readily provides this kind of information. In the SMB networking arena, however, clients and servers not only require this type of information, but also need information used by the NetBIOS layer of networking. This layer, immediately below SMB in the OSI stack, has it own conventions for communications among other hosts on the network (that is, the NetBIOS names of other hosts). Capability to determine the NetBIOS name depends on a service called the NetBIOS Name Service (nbname). This service, for which the default port binding is UDP port 137, capitalizes on several different sources, including DNS, the Windows Internet Name Service (WINS), direct queries, and broadcasts, to build "name caches" that hold the information about other machines that NetBIOS mechanisms need. Using its own naming conventions, NetBIOS subjects the name that the system administrator assigns to a host to a series of transformations to produce a NetBIOS name.6 Table 3.2 shows these steps.

Table 3.2 How NetBIOS Names are Derived



Convert characters of computer name to ASCII

"GLE" becomes ASCII 71 76 69

Convert ASCII characters to hexadecimal

71 76 69 becomes 47 4C 45

Add 20 until there are 16 byte pairs

47 4C 45 20 20 20 20 20 20 20 20 20 20 20 20 20 20

Split into two 168-byte hex strings

47 4C 45 20 20 20 20 20, and 20 20 20 20 20 20 20 20

Split each byte pair into nibbles (4-bit chunks) of individual bytes

4 7 4 C 4 5 2 0 2 0 2 0 2 0 2 0 2 0 20 2 0 2 0 2 0 2 0 2 0 2 0

Add hex value of "A" (41) to each byte pair

45 48 45 4D 45 46 43 41 43 41 43 41 43 41 43 41 43 41 43 41 43 41 43 41 43 41 43 41 43 41 43 417

If the name is longer than 15 bytes, the additional bytes are truncated. Then a final byte is appended at the end to indicate the status or meaning of the NetBIOS name. Therefore, the NetBIOS name consists of a 15-byte unicast8 hexadecimal value plus a 1-byte trailing hexadecimal value. This last byte pair can assume any of the hexadecimal values indicated in Table 3.3.

Table 3.3 Meaning of the Trailing Hexadecimal Values of a NetBIOS Name9


Meaning or Status


Computer names and workgroup names*


Master browser


Messaging/alerter service; username of user with logon session


Names of available resources on server


Name of domain master browser


Name of domain controller


Response to election announcement

You will see NetBIOS names when you use a packet-capture device to examine network traffic. If your protocol analyzer does not convert NetBIOS names back to computer names, you may have to perform this conversion to identify specific machines referenced in packets. Also, because NetBIOS includes mechanisms for identifying computers with NetBIOS and other sessions to a given host, you can enter the nbtstat command into a Windows command line with the following options to remotely or locally identify these sessions in addition to other information:

nbtstat (-a targethost] [-A IPaddress][-c][-n][-r][-R][-s][-S][interval]

To get a dump of a host's sessions table with the destination IP addresses, for example, enter the following:

nbtstat -S

Similarly, given its host name you can get a host to dump its name table (its name cache) that it creates by entering the following:

nbtstat -a <hostname>

You can get a host to dump its name cache given its IP address by entering the following:

nbtstat -A <IPaddr>

Requests for name cache dump are often called wildcard node status queries. The value of the nbtstat command (the execution of which is not limited to priveleged users) to remote attackers goes without saying.

Client/Server Communications

How are SMB-based client/server communications established? A series of conventions are used in which both client and server pass data to each other until, if everything has gone right, the server establishes the SMB connection to a specific point in its hard drive or other device. This negotiation process occurs in four distinct stages: establishing a TCP session, negotiating a dialect, establishing a SMB connection, and accessing resources.

Stage One: Establishing a TCP session

The first stage of the negotiation process begins when a client sends a Session Request Block to the server. The names of both the server and client (in NetBIOS format) are included in the request. The server does not check the IP address of client, and immediately creates a TCP connection with the client on port 139 of the server (normally TCP 139) on the server.

Stage Two: Negotiating a Dialect

In this stage, the main purpose is to discover the "highest" version of SMB supported by both client and server. What this in essence means is discovering which implementation of MS Networks (the basic LAN implementation used in Microsoft networking) has been used in both the client and server. The particular implementation is known as the "dialect." The various types of dialects, starting with the earliest and ending with the most recent are as follows:

    PC Network Program 1.0

    XENIX Core

    Microsoft Networks 1.03

    LanMan 1.0

    Windows for Workgroups 3.1a


    LanMan 2.1

    NT LM 0.12

The client sends the names of all dialects that it supports. Therefore if the client is a Windows NT Workstation 4.0, it will understand the most sophisticated dialect, NT LM 0.12. It will, however, forward to the server all the dialects in the preceding list. When the server receives the dialect name(s) from the client, it responds with a dialect list index showing which to use.10 It also sets security flags (using the smb_flg and smb_flg2 fields in SMB packets) based on how sophisticated a version of SMB has been negotiated. It may additionally send 8 bytes of ciphertext for authentication; whether this is done depends on the particular authentication program. If any part of the dialect-negotiation process fails, the TCP session is terminated.

Stage Three: Establishing an SMB connection

The third stage of establishing SMB communications between a client and server once again starts with the client. The client forwards a session setup request containing a header that includes data, such as the user ID, domain name, operating system, and other (variable) information. The header is usually only 16 bytes long. The server responds by sending a token incorporating the same types of information included in the session startup request, but this time applicable to the server. Unfortunately as discussed earlier in this chapter, each user ID is not necessarily unique across sessions! If the client has sent a username that the server cannot recognize (that is, the user ID is unknown to the server), one of two results occur: denial of access (and, therefore, failure to create an SMB connection); or creation of a "null session," in which the SMB connection is nevertheless established but without a defined user ID. The big problem here is that the strength of authentication depends on the client, not the server. Incidentally, more negotiation must take place to establish an SMB connection if "share-level" security (an option in Win9x, but not in Windows NT) is in place.

Stage Four: Accessing Resources

In the fourth and final stage of the negotiation process between client and server, the server locates the specific point (for example, in the hard drive) to which the SMB connection will be made. The \PIPE\Srvsvc service is used to locate the device, and then a "tree connect" mechanism (based on the Inter Process Communication (IPC) mechanism in MS Networks) is used to access the resources (for example, files, directories, named pipes) within this device. The connection request includes the name of the requestor, TID, password (but only in the case in which share-level security is in place), and the name of the type of service being used to access the resource. The client then returns a 2-byte SMB header with the TID to the server after the tree connection is in place to acknowledge to the server that the connection request succeeded. At this point, a share connection is established, allowing the client to access resources with the restrictions imposed by both share permissions and the file system. (Chapters 5, "Configuring Windows NT Server for Security," and 6, "Maintaining Windows NT Security," provide details concerning how these restrictions work.) Because share connections time out if they are not active, a primitive type of SMB echo mechanism keeps the share active.

  1. Many of the facts and ideas in this chapter were developed by Hobbit, an independent vulnerabilities researcher (see http://www.avian.org). His white paper, "CIFS: Common Insecurities Fail Scrutiny," was the basis for most of the content of this particular section of the book.

  2. For more information on how to encode/decode NetBIOS names, refer to Knowledge Base article Q194203.

  3. The result if the NetBIOS name were to be converted back to ASCII would be EHEMEFCACACACACACACACACACACACACA.

  4. Unicast is a format in which each byte pair is separated from the next by a space.

  5. This list is not exhaustive.

  6. The server also volunteers its file system type to the client during negotiation.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020