NetBIOS in the hands of a hacker

    This article will go a short story about what we can tell such a familiar thing like NetBIOS . What information can he provide for a potential attacker / pentester.

    The demonstrated area of ​​application of reconnaissance techniques relates to internal, that is, isolated and inaccessible from the outside networks. As a rule, such networks exist for any even the tiniest company. NetBIOS

    itself is used, as a rule, to obtain a network name. And that will be enough to do at least 4 things.

    Host discovery


    Due to the fact that NetBIOS can use UDP as a transport, its speed makes it possible to detect hosts in very large networks. So, for example, the nbtscan tool , included in the package of the same name, can resolve a network address of the type 192.168.0.0/16 in just 2 seconds (it can put a network), while traditional TCP scanning will take tens of minutes. This feature can be used as a host sweep technique in very large networks that are not known about before starting nmap. Although the result does not guarantee 100% detection, since windows hosts will mostly respond and not all, it will still allow you to determine approximately in which ranges live hosts are.

    Host identification


    Using the results of obtaining names from ip-addresses:

    image

    you can see: in addition to the fact that the name reveals the owner of the workstation (although this is by no means always the case), one of the addresses clearly stands out from the others. We can see that the name KALI was received . This behavior is typical, as a rule, for the unix implementation of SMB / NetBIOS as part of the samba software package or very old Windows 2000 .

    Getting the name KALI , while on other hosts this < unknown > indicates the presence of the so-called null-session . At default settings of the SMB server on linuxprone to it. Null-session only allows you to get quite a lot of additional information, such as a local password policy, a list of local users, groups and a list of shared resources (ball), absolutely anonymously (and we didn’t enter any passwords, as shown in the screenshot):

    image

    Often on linux SMB -servers are publicly accessible balls, not just for reading, but even for writing. The presence of both of them carries various threats, the use of which is beyond the scope of this article.

    NetBIOS also allows you to get the names of all types that the workstation stores:

    image

    in this case, it allows you to find out that the host is also an ARRIVA domain controller .

    It is also worthwhile to pay additional attention that NetBIOS allows you to get a mac address. Moreover, unlike arp requests, NetBIOS requests can go beyond the subnet. This can be useful if, for example, you need to find a laptop or specific hardware on the network, knowing its manufacturer. Since the first three octets of the mac address identify the manufacturer, you can send similar NetBIOS requests to all known subnets to try to find the right device (http://standards-oui.ieee.org/oui.txt).

    Domain Membership Determination


    Often, when moving through internal corporate networks, it is necessary to attack the workstation included in the domain (for example, to elevate privileges to the level of a domain administrator) or vice versa. In this case, NetBIOS can again help:

    image

    In this case, using NetBIOS , all names of all types were obtained. Among them, you can see, in addition to the name of the PC (what has already been received before), the name of the working group. By default for windows, it is usually something like WORKGROUP or IVAN-PC , but if the workstation is in a domain, then its workgroup is the domain name.

    So using NetBIOSyou can find out in the domain whether the workstation and, if so, in which.

    If you want to get a list of domain hosts within the subnet, then one broadcast request with the name of the domain you need is enough:

    image

    as a result, all hosts that are in this domain will respond.

    Discovery of multihomed hosts


    And finally, another probably very little-known technique, which is simply indispensable for finding ways to secure, possibly even physically isolated networks. It can be workshop network of enterprises stuffed with controllers. For an attacker, access to this network means an opportunity to influence the technological process, and for an enterprise there is a risk of huge losses.

    So, the bottom line is that even if the network is isolated from the corporate network, often some administrators, either because of their laziness, or somehow, like to raise another network card on their PCs to access this same network. Moreover, all this happens of course, bypassing all sorts of rules of corporate firewalls. Convenient, yes, but not very safe, if you are hacked, then you will become a bridge to this network and bear responsibility.
    However, for the attacker there is one problem - to find the very administrator who joined the secure network in a similar illegal way. Moreover, this is not an easy problem for the network security personnel themselves. In large enterprises, this is truly a difficult task, as if to find a needle in a haystack.

    In this situation, there would be two obvious options for an attacker:

    1. try to use each PC in the corporate subnet as a gateway to the desired network. It would be very convenient, but this is rarely seen, because on windows hosts ip forwarding is almost always disabled. Moreover, such a check is possible only within its own subnet, and it also requires the attacker to know the target address from the isolated network exactly
    2. try to remotely log into each host and execute the banal ipconfig / ifconfig command . And here everything is not so smooth. Even if an attacker secured the rights of a domain administrator, nobody canceled the firewalls and local firewalls. So this task is not 100% automated. As a result, it remains painful to go to each host, overcoming firewalls (often blocking exactly 445 / tcp port), hoping to finally see the coveted network interface.

    However, everything is much simpler. There is one extremely simple trick that allows you to get a list of network interfaces from a given host. Let's say we have a certain host:

    image

    this is the reverse resolver ip-address → network name. If we now try to make a direct resolv network name → ip-address:

    image

    then we will find out that this host is also a gateway (apparently) in some other network. It is worth noting that in this case the request was broadcast. In other words, hosts will only hear it from the attacker's subnet.

    If the target host is outside the subnet, then you can send a targeted request:

    image

    In this case, it can be seen that the target is outside the attacker's subnet. Using the -B switch, it was indicated that the request should be sent to a specific address, and not to the broadcast one.

    Now it remains only to quickly collect information from the entire subnet of interest, and not from a single address. To do this, you can use a small python script:

    image

    And after a few seconds:

    image

    It is the dedicated host, in this improvised case, that would become the first target of the attacker if he pursued the network 172.16.1 / 24.

    image

    Duplicate names on different ip indicate that the host also has two network cards, but on the same subnet. It is worth noting that NetBIOS does not disclose alias (which can easily be calculated via arp requests as ip with the same mac ). In this case, the ip addresses have different macs .

    Another example of using this technique is public Wi-Fi. Sometimes it is possible to meet a situation when among the guest devices, personnel working in the closed corporate segment are connected to the public network. Then with the help of this reconnaissance technique, an attacker can very quickly figure out a way for him to enter a closed network:

    image

    In this case, among 65 public Wi-Fi clients, there were two workstations with an additional interface, probably related to the corporate network.

    If sometimes filtering between 445 / tcp ports is observed between network segments or directly at workstations, which prevents remote login to the system (remote code execution), then in this case NetBIOS resolves namesthe 137 / udp port is used, the conscious blocking of which is almost never encountered, because the network usability will be severely affected, for example, the network environment may disappear, etc.

    As they say, enumeration is the key
    Is there any protection against this? It is not, because it is not a vulnerability in everything. This is only the standard functionality of the little that windows has by default (in linux, the behavior is slightly different). And if you, suddenly inconsistently, bypassing the rules of network routing joined a closed segment, then the attacker will certainly find you and do it very quickly.

    Also popular now: