Network Poisoning

Anyone that has ever had to deal with an internal network penetration test knows the big 3 of network poisoning attacks. Those are Link Local Multicast Name Resolution (LLMNR), Network Basic Input/Output System (NetBios), and Multicast Domain Name System (mDNS). We can also add an additional network attack utilizing IPv6 by reassigning the default DNS server by leasing an IPv6 address to all Windows hosts that do not have one, we will ignore that for now. These network poisoning attacks are pretty standard in the offensive security world but are still very effective on MOST enterprise networks. Yes, the poisoning itself is loud and yes, you are dependent on other hosts in the environment for any movement. The speed of vertical privilege escalation can be exponential if other vulnerabilities are in place such as smb signing not being required. All it takes is a single relay or something like a backup administrator account to get access to an entire domain. Let’s talk about each one, what they do, and why we use them in pentests.

LLMNR is defined in RFC 4795 back in 2007. A host on a domain utilizes DNS to be successfully routed to an IP address. You can think of DNS as a phonebook to map names to numbers. LLMNR is a fallback for DNS. If there is no resource the DNS knows, LLMNR will perform name resolution for any host that is on the same local link. This allows both IPv4 and IPv6 hosts to route by identifying resources by utilizing UDP on port 5355. LLMNR creates a unicast address (224.0.0.252) to send and receive all queries. All communication can be facilitated within the same subnet whenever DNS is not available or practical to use.

What can we do as attackers with LLMNR? By sitting as a man-in-the-middle, we can capture a couple of things. The first being credentials. Utilizing a tool like Responder, we can capture NTLMv1, NTLMv2, clear text, and Basic Auth credentials. These can either be taken offline to crack or used within their respective services. Attackers can also do session hijacking and relay credentialed access to vulnerable hosts. This effectively allows us to impersonate another user within the network.

NetBIOS is defined in RFC 1001 and 1002. It is a network protocol that allows legacy computer applications to use TCP/IP network. Windows devices that use NetBIOS will check hosts over TCP/IP but will also be assigned a NetBIOS name. This is known as the Windows Internet Naming Service (WINS). A Windows server will map server names and locations to IP addresses just like DNS with a Microsoft implementation called NetBIOS Name Server (NBNS). This service was developed back in the 1980’s. This is all communicated on 3 different services, TCP port 139, UDP on port 138, and both UDP and TCP on 137. NetBIOS still plays a significant role in Windows networking environments but includes a security risk when not properly configured.

What can we do as attackers with NetBIOS? We can use Responder again to sit as a man-in-the-middle to intercept credentials like hashes and passwords being passed between hosts. Session hijacking can be effective with this protocol as well. NetBIOS can be leveraged to enumerate other network devices, IP addresses, shared resources, and services running between those. Brute Force attacks can be made against those services like file and print sharing to guess weak passwords.

mDNS is defined in RFC 6762 and came out in 2000. mDNS is zero configuration (zeroconf) protocol. This means everything is done automatically within the network and no manual addition of DNS services, DHCP server, or individual device networking is needed. This works with 3 requirements: Automatic IP address selection; Link-Local addressing to create an IP address range from 169.254.1.0 to 169.254.254.25; Run a query to resolve with the given IP. That info can be found within THIS IBM doc. What mDNS does is create a multicast address (244.0.0.251) and sends/receives network packets from anywhere within a local network. Most often you will see this on IoT devices, printers, and wireless speakers. More of the same in terms of use case. mDNS does name resolution, discovers services running on hosts, and enables network discovery.

What can we do as attackers with mDNS? As expected, we can intercept traffic as a man-in-the-middle for credentials and spoofing attacks. Network and service enumeration is possible as well to see if a host is running something like Teamviewer. This is all done from specific queries or impersonating legitimate network services.

Running any kind of vulnerability scan will show service detection for hosts that are running any of these protocols. This is excellent for giving to a client, but this comes with a caveat. All the detected hosts are detected during a single point in time test. Having to rerun a vulnerability scan can be an extremely time-consuming task as well as creating unnecessary workload on a device. This can be important if you have sensitive devices within your environment.

We can run something like Responder in analyze mode in the background for several hours to try and capture as many hosts as we can. Other tools work well for something like NetBIOS with nbtscan (this comes preinstalled in kali). There are other less popular tools to exploit LLMNR and mDNS, but no real detection scripts have been made that we could find. So, we made one!

TrafficScan (https://github.com/samiam1086/python-tools/blob/main/trafficscan.py) is a tool created by our two consultants Daniel Cornett and Kyle Meyer. This is a simple tool that runs the associated queries for each protocol and prints out the susceptible IPs and hostnames. We cannot get around the scan being a point in time result as that is the nature of testing on networks, the host needs to be alive. Running TrafficScan will keep noise to a minimum, not be intrusive to the hosts in the scan, and provide easy reporting to the client. This tool works by sending specialized DNS queries to the different protocols. If we get a response back, we can identify the IP and hostname that submitted a response. We can conclude the protocol is available from that host. TrafficScan will output the associated hosts in separate txt files and a conglomerate xlsx for uploading.

Please let us know if you have any thoughts or suggestions! Go out and Hack the Planet!