Windows Name resolution mechanism and defect Utilization

Windows Name resolution mechanism and defect Utilization

As a popular science article, this article describes the name resolution mechanism in Windows systems, and also mentions several ways of using the name resolution mechanism defects for Intranet attacks.

0x00 introduction to Windows Name resolution

TCP communication is based on IP addresses. "name resolution" refers to the process of resolving the name of the computer to be accessed to an IP address.

Name type in Windows

In Windows, there are two types of names: Host Name and NetBIOS name.

Host Name

In a narrow sense, a host name is the name of a host just as it literally means. In a broad sense, it not only contains the name of a computer, but also domain names on the Internet.

Because the domain name is displayed in A tree and also A host name, the host name is hierarchical and consists of A maximum of 255 characters. The Allowed characters include ~ Z, ~ Z and the character "-". In the domain name system, a domain name that identifies the DNS name of a host is called the Fully Qualified Domain Name (FQDN), and The FQDN is "The host name and the primary domain name suffix are combined. For example, the FQDN name of seclab.her0in.org is seclab.

NetBIOS Name

In Windows, another name is NetBIOS name. To be precise, NetBIOS name is not a name system, but a programming interface of the Windows operating system network, allows communication between hosts using the NetBIOS name. The communication process is based on the NetBIOS protocol. After Windows is installed, the system uses the computer name as the NetBIOS Name of the current host by default. The maximum length of NetBIOS is 16 characters. The last character is not configurable and is used to specify the service type of NetBIOS. If the computer name is less than 15 characters, use spaces to complete to 15 characters. If the computer name is more than 15 characters, the first 15 digits are truncated. Common NetBIOS suffixes include 0x20 (file and print service), 0x00 (Workstation Service), and 0x03 (Reporter Service.

Run the nbtstat-n command to view the NetBIOS Name of the local machine.

Run the nbtstat-A ipaddress command to view the NetBIOS Name of the specified IP host.

0x01 Windows Name Resolution Protocol

In Windows, there are three name resolution-related protocols.

DNS protocol for Windows Name resolution

The DNS protocol is the most important and preferred name resolution protocol for the operating system. Almost every operating system supports the DNS Protocol. At the same time, the DNS protocol supports IP v4 and IP v6. During name resolution, the DNS protocol does not have any local database files on the client and relies entirely on the DNS server. The listening port is UDP/53. On the client, you can use the ipconfig/displaydns command to view the local DNS cache, and use the ipconfig/flushdns command to clear the local DNS cache.

The DNS name resolution process is as follows:

Read the local DNS cache (including the local hosts file). If the cache does not exist, the system requests the DNS server configured in the network configuration. If the DNS server does not respond, the request fails. Otherwise, the DNS server processes user requests.

NetBIOS protocol for Windows Name resolution

In addition to DNS, NetBIOS (network basic input/output system, network basic input/output system) is also used for name resolution in earlier versions of Windows. The NetBIOS protocol name resolution described in this article is the name resolution type of the NetBIOS over TCP/IP protocol defined by Microsoft later.

The nbt listening port is UDP/137. The name resolution form is to send a broadcast packet to the subdomain of the current host. Therefore, when you use the packet capture tool to capture packets in the LAN, you will always receive many NBNS packets.

Because the NetBIOS protocol performs name resolution, the UDP broadcast package is sent. Although it is fast and requires no additional configuration, the broadcast package cannot span the domain and also increase some network traffic. Therefore, Microsoft later launched the WINS (Windows Internet Name Service) server, when the computer is configured to use the WINS server for name resolution, the client will directly communicate with the WINS server for unicast communication, which can make up for the NetBIOS protocol for name resolution using broadcast.

To sum up, the NetBIOS protocol name resolution process is as follows:

Check the local NetBIOS cache. If no request name is in the cache and the WINS server is configured, next, a request will be sent to the WINS server. If the WINS server is not configured or the WINS server has no response, a broadcast will be sent to the current subdomain. If no host response is received after the broadcast is sent, the local lmhosts will be read. file

The lmhosts file is located in the C: \ Windows \ System32 \ drivers \ etc \ directory.

Run the nbtstat-c command to view the NetBIOS cache of the local machine.

UseNbtstat-RCommand to clear the NetBIOS cache of the Local Machine

LLMNR protocol for Windows Name resolution

Although DNS protocol name resolution is efficient, you need to configure a server in the LAN as the DNS server. In some cases, you need to configure a WINS server for NetBIOS protocol name resolution, the NetBIOS protocol does not support IP v6. Therefore, to make up for these shortcomings, Microsoft launched an end-to-end Name Resolution protocol after Windows Vista-Local Multicast Name Resolution (LLMNR.

LLMNR is also called multicast DNS because its data packet format is similar to that of DNS data packets. The listening port is UDP/5355, supports IP v4 and IP v6, and this Protocol is also implemented in Linux. The DNS name is end-to-end. The IPv4 broadcast address is 224.0.0.252, And the IPv6 broadcast address is FF02: 0: 0: 0: 0: 1: 3 or FF02 :: 1: 3.

The name parsing process of LLMNR is as follows:

Check the local NetBIOS cache. If the cache does not exist, other hosts that send broadcasts to the current subdomain receive and check the broadcast package, if no host response is received, the request fails. 0x02 Windows system name resolution order

Two factors affecting name resolution in Windows

Operating system version

From the above section, we can find that not all operating system versions support the above three protocols.

Windows 2 K, XP, and 2K3 only support DNS and NetBIOS. Therefore, for Windows of this type, DNS name resolution is performed first. If the DNS resolution name fails, NetBIOS name resolution is performed.

After Windows Vista (including 2K8, Win7, Win8.x, and Win 10), the above three protocols are supported. In such Windows systems, the DNS name resolution sequence is as follows, if the DNS resolution name fails, LLMNR will be used for name resolution and NetBIOS name resolution will be used.

Network Node Mode

Another factor that affects Windows system name resolution is the network node mode of the current host. You can run the ipconfig/all command to view the network node mode of the local machine, for example:

Figure 1 Local Network Node Mode

The Network Node mode mainly affects the NetBIOS name resolution process. It is used to query the WINS server first or broadcast in the subnet domain. The specific and node modes are described as follows:

B-node (broadcast, broadcast)

Windows uses broadcast for name registration and name resolution. According to the gateway configuration, a B-node client cannot send packets beyond the LAN range. However, Node B is not suitable for large networks. In fact, Microsoft modified the standard Node B type. When Windows tries to resolve the name, first check The LMHOSTS name cache. If this does not work, windows sends a broadcast. If the broadcast still fails, Windows checks the actual LMHOSTS file.

P-node (per-to-per, peer-to-peer)

This method does not use broadcast, but registers their names on the WINS server in the network when the computer starts. When the computer needs to resolve the names, it sends a resolution request to the WINS server. This method is only valid when the WINS server is running normally. If the WINS Server fails, the name cannot be parsed.

M-node (mixed, hybrid)

Windows uses Node B and node P together, and Node B is used by default. If node M cannot use broadcast for name resolution, it uses the WINS server of node P to complete the work.

H-node (hybrid, hybrid)

B and P nodes are also used in combination. However, if the WINS Server fails, the work of B nodes is used to complete the work. This node mode is also the default node mode in Windows.

0x03 use Windows Name resolution mechanism defects for Intranet attacks

Common attacks that use Windows Name resolution mechanisms include DNS Spoof, NBNS Poison, LLMNR Poison, and ICMP Redirection.

You can use the Responder from SpiderLabs or the ZARP toolkit to perform the above attacks.

The LLMNR Poison attack environment is as follows:

Attacker host (Linux) IP address 192.168.237.htm victim host (Windows 8.1) IP address 192.168.237.129 the two hosts are in the same LAN

After the attacker starts the Responder, when the victim accesses a host that does not exist in the current LAN, The LLMNR Poison attack is triggered, as shown in:

Figure 1: Target Host PING a host that does not exist in a LAN

Figure 2: Responder responds to the LLMNR broadcast package and performs a Poison attack

Figure 3: added the IP Address Record of the host under Poison attack to the NetBIOS cache of the victim's host

In the above attack demonstration, we have confirmed the effect of the LLMNR Poison attack. We can perform the LLMNR Poison attack by allowing the victim to access the sharing of nonexistent hosts. In this way, we can obtain the HASH of the victim host, after obtaining the HASH, you can perform brute-force cracking. If it is a weak password, the password can be cracked. You can also use 401 authentication to access an HTTP server that does not exist to obtain the client's HASH, as shown in:

Figure 4: Share a victim accessing a nonexistent host

Figure 5: LLMNR Poison attacks get the HASH during SMB Verification

Figure 6: brute-force HASH cracking using john