NetBIOS Enumeration – From Linux & Windows

On older versions of Microsoft windows, and the current versions you will find some common ground. To identify a remote box (but not too quickly) as a Microsoft NT or 9x box from your nmap scans you will need to check for a port range of: 135-139 for windows 9x and on NT systems port 445 and they must be open, or listed on the scans. What this signifies is that the remote server has SMB/CIFS open and is a common sign of RPC/DCOM (most notably port 135).

Please be advised that this section, the tools detailed (nbtscan) can also be launched for windows and should accompany the materials. Therefore the windows port will not be covered as it will be redundant.

Through this, you can use tools to begin enumerating the NetBIOS shares, and information from the box. In this example, our focuses will be on the grounds of SMB information gathering and enumeration. To cut out the time it takes to scan, you can launch the nbtstat tool against a bunch of targets to see what it reports back. However, without a valid scan or nmap it can be tiresome.

The first tool we will take a look at is the nbtscan tool. What the nbtscan tool will do is scan the network (in CIDR form or single IP address), and dump information about the netbios names (e.g: sysbox, netbios: \\sysbox instead of the common IP addresses – again this will help solidify that box XYZ is in fact a windows machine). Below in figure 1.0 we demonstrate the usage of the nbtscan tool against a vulnerable windows 2000 machine we've setup:

Figure 1.0 demonstrating an nbtscan on a single address.

The next example, displays the nbtscan tool scanning a net block (cidr 16) and discovering locations with the SMB shares enabled. Notice that for cutesy we have blotted out other services.

Figure 1.1 displaying a /16 address scan.

In the following example, we've brought additional VM's online and our output is shown in figure 1.2:

Figure 1.2 displaying a listing of 3 machines (xp, 2k, and a NAS)

from here we can see that each machine is running some form of netbios. We can also determine that these machines are Microsoft windows boxes. Furthermore, this can help us in our exploitation tactics with the combined efforts of p0f that we learned about in Enumeration → operating system identification, P0F.

Using Standard Windows Netview – Finding Shares

NetBIOS is a service that runs on microsoft windows systems to provide file and print sharing. From systems of 9X (which encompasses windows 95-98, and ME) the port is run off TCP 135-139. The latter of the systems the, NT generation is run off port 445. When we discuss the operating systems, we will refer to each generation by its #X generation; e.g: windows 3x, windows 9x and windows NT. This will include windows 3.1 as windows 3x, windows 95-ME as windows 9x and windows 2000,XP, 2003, Vista as windows NT.

NetBIOS enumeration can serve up a lot of information. This can range from groups on the machine, to specific users, and shares being served up. Furthermore, while understanding how file and print sharing works; it's also essential to point out (and later highlight the use of such a technique) the windows null session.

As with any, Microsoft windows OS most of the tools you'd be using to breach and check into services will come bundled with the windows NT resource kit, or the basic of the tools come coupled with the OS itself. The tool that we will be utilizing for most of our discovery and enumeration on windows systems is the net view tool.

In the examples that we are showing you; we are changing the information, and or hiding the information being presented. However, the outcome shall always remain the same when reproduced outside the classes or this literature.

Of the net view tool switches that you'd be utilizing will be highlighted in table A figure 1.0.

Figure 1.1 demonstrates a successful net view on a local machine:

Figure 1.1 demonstrating a simple “net view” command displaying computer information.

While issuing the additional command of: net view /domain will display all the domains that the computer is currently connected to. Figure 1.2 demonstrates the use of the /domain set.

Figure 1.2 Demonstrating the /domain switch.

When an attacker is willing to gather the information in regards to a particular system, or domain on a windows network, the usage of such a command is accomplished by entering net view /DOMAIN:domain_name with this the attacker can gain additional details on that particular domain and extrapolate more information.

For the sake of a demonstration purpose, we have loaded the following VMs: Server 2003, NT 2000, and Windows XP sp3 When we issue the following command: net view /domain we get the following output:

Figure 1.3: issuing a net view command.

As you can see, the domains ndsnet, sysinternals, and workgroup are present. We can drill down the listing by issuing the: net view /domain:sysinternals command in order to obtain additional information. Figure 1.4 demonstrates this:

Figure 1.4: displaying the remote system (on the same network).

With this information displayed, you can connect to the shares they are serving up. In this case we see that the share is \\IRS-3432928EDEF. In essence, this will provide you with locations for shares on the systems you are pilfering. Common tasks you may want to provide: password guessing, and testing to see if guest accounts are still enabled, and finally – testing accounts with no passwords!

Windows and Null Sessions

The windows null session is a method of “authentication” into an SMB or system which will allow you to bypass the windows authentication process altogether. In the terms and meanings, NULL refers to the non-existence of user name and password. If you do find effected machines, or vulnerable systems issuing command in figure 1.0:

Figure 1.0 a successful null session connect.

From here, to test the connection you can issue the command: net view \\192.168.0.10 (where the IP address is the IP of the system directly effected by the vulnerability). If you can enumerate shares, you have successfully connected to the system. If successful, you will see data as follows (full view):

Figure 1.1 demonstrating a successful null session attack

We have tested utilizing IP Addressing and to our trials have been unsuccessful (and we will gladly give you the answer why.) If NetBIOS is not piked over TCP/IP it will not work. Thus you will be forced into performing your testing against the targets with their names. As pointed out previously you will then be forced into utilizing your nbtscan output. However, such scans may be hampered if the attackers ARE NOT on the same network as the unfortunate user. Figure 1.2 demonstrates a successful run with NetBIOS over TCP/IP:

Figure 1.2: NetBIOS over TCP/IP exploited null session over IP.

If this system was identified as a windows NT 2000 box, one can use the RPC Dcom exploit to break into the remote server for full root access. For more information, please see the “Exploitation” section for more details.

Covering your tracks

If you've heard it on T.V. Shows you're probably going to hear it in here, too. It's not uncommon for a hacker to cover his or her tracks once a system or network has been penetrated. One of the common methods that this will happen is with an application for NT 2000, and NT Server 2003 machines that is known as WinZapper. Please do not confuse WinZapper with the, Trojan application that masquerades with the same name.

The method by which WinZapper operates would need to be through the execution of a VNC or the establishment of a remote view (Terminal Services) which one can interact with the windows desktop; considering the application is GUI based and not CLI.

WinZapper allows remote attackers to delete specific security events from the NT work stations. Below is a view of the WinZapper application in use:

Figure 1.0 Demonstrating System event Mon Feb 07 5:55:42 selected.

Considering we are highlighting an event (you must use the keyboard for this), we will focus our efforts on this event herein, below is what happens when we delete said events (seen from the view of the administrator, and inside winzapper):

Figure 1.1 Error seen by administrator after access to the logs (tell tale sign something is wrong)

Figure 1.2: Deleting an event, as you can see the system must be restarted.

Figure 1.3: Demonstrating the listing of 4 logs when the previous contained 5.

What WinZapper demonstrates is that specific events can be deleted, and not the entire system log. It should be known that you will need access to the administrators account in order to run WinZapper! As if you are not administrator the file will open and close. With this type of attack the system log will be inaccessible and other errors may crop up when attempting to view the security logs.