This is an incredibly useful chapter, and it covers attacks pertinent to network services and local networks (wireless networks are covered in the next section). We will be going through attacks on devices like switches and getting a general understanding of the weakness in services like FTP, SMB - which can reside on internal networks.

The commonalities among every network

Here we are going to find some principles that persist among pretty much all internal networks. To start, let’s look at the infrastructure of an internal network. For the sake of this section we’re going to assume that things are physically connected by Ethernet and there is a switch on the network - by which we can leverage arp to get the MAC information on each computer . This is the physical address which is stored on a given port of the switch and uses it to check against incoming packets. IP is still used within an internal network, but these internal IP addresses are usually 192.168.1.* as they don’t need to be publicly viewable - only the router needs a public IP.

To begin, I’ll download some general purpose tools for kali that can help with gathering ARP information:

The information we gather should enable us to understand the MAC of the switch, the MAC on other machines and hopefully we should be able to do a MAC-based Man-In-The-Middle (MITM) attack. This is where we have to be on the same internal network (otherwise you’re doing an IP-based MITM) , poisoning the routing tables of the switch to pass the victim’s packets to us - which we forward to the victim , who thinks we are the switch. This can be done with tools like ettercap , ARPspoof and even metasploit has a couple modules.

Man-in-the-Middle Attack

Now, to insert ourselves as a go-between , we’re essentially trying to force a proxy onto the client and whatever website they want to visit. This can be done in a variety of different ways and it depends on the network … Regardless of whether Linux or Windows is prevalent , attacks like DNS cache poisoning can still work . This attack could happen if:

• We poison the records in the client’s computer, so for facebook.com they have a different IP now set which takes them to our bogus site.
• We poison the DNS server itself and make the change here.
• Or, if neither side can directly be landed on, we have to intercept the request packets from a newly setup computer - who doesn’t yet know of the address for facebook.com and so we pretend to be the local DNS server and try to provide an answer for them; however, this option is so unlikely and needs such good timing you practically will never see it.

So what else could we do ? Well, let’s say we’re on a Windows network. Windows devices will have by default not one , but two ways of finding hosts on the network that can resolve requests for servers or other computers . The first was NetBIOS , which is a protocol for finding other computers and each Windows computer had a NetBIOS name and an IP address - by which they could query each other and ask questions about other computers. It was first developed in 1983 but has since come a long way, no longer running on rusty old principles , the protocol now runs over TCP and is now called NBT for NetBIOS over TCP.

NBT has three specific services

• The Name Service - NBT-NS
• The connectionless communication service to allow the protocol over UDP
• The sessions communication service to allow the protocol over TCP

Now the name service can run atop either of these communications layers - usually its UDP , port 137. The name service primitives offered by NetBIOS are:

• Add name – registers a NetBIOS name.
• Add group name – registers a NetBIOS “group” name.
• Delete name – un-registers a NetBIOS name or group name.
• Find name – looks up a NetBIOS name on the network.

NetBIOS names are different from hostnames and so they could be completely different - or they could be made the same , depends on their purpose.

Now then, I mentioned two ways in which a Windows machine could find other hosts and get names resolved - the second method is called Link-Local Multicast Name Resolution (LLMNR). This is a “rawer” form of name resolution as we’re not adding much, this is a protocol which sits on a link-local network only and isn’t as cross-country as NBT - being that TCP works over the internet would you believe. LLMNR works on the link level and mirrors the DNS hierarchy itself , keeping hostnames and mapping them to IP addresses. A client which doesn’t have the IP for a particular host or website can use LLMNR, which means broadcasting the message over all to all connected clients who have the port 5355 open and the IP

 224.0.0.252

which is given to all machines who are LLMNR listeners - in addition to their private IP.

For a Windows computer - this is the hierarchy by which they try to evaluate a network resource like facebook.com

1. Check to confirm whether the request is for the local machine name.
2. Check the local cache of recent successfully resolved names.
3. Check our local hosts file, which is sort of like the mini-DNS on the client. Depending on the device this might’ve been loaded into cache and so we move to the next step.
4. Query a DNS server, if so configured.
5. If LLMNR is enabled, broadcast LLMNR queries across the local subnet to ask its peers for resolution.
6. If NetBIOS is enabled, attempt NetBIOS name resolution via broadcasting NetBIOS-NS queries to the local subnet if the name is not in the local NetBIOS cache. This step might use a Windows Internet Name Service (WINS) server if so configured, as well as the LAN manager hosts (LMHOSTS) file.

With this , when someone is really desperate and they can’t find an SMB share they will use the NBT-NS calls to find someone on the network that is the share. That’s where we come in and claim we’re that SMB share , communication begins and they send us their SMB credentials assuming we’re the real deal - oops we just poached them , but thank you !

Resources for exploiting LLMNR and NBT and properly defending yourself can be learned here:

• Basics of NetBIOS and LLMNR
• NetBIOS and LLMNR explained
• Using Responder to grab credentials

Replay and Relay attacks

The first is where we use some sort of network monitoring tool like tcpdump, wireshark etc and capture packets from the client-server communications and try to find the packet which was sent to somewhere like /login which we can then presume has some encrypted credentials in the message body. We would then capture that packet and see if we could replay it - to allow us to login . Most cookies nowadays though have an expiration within them to avoid this . One of the most powerful attacks still seen in the wild is to capture NTLM hashes from SMB servers or Active Directory environments and then log in with that account as you can provide that hash and not the password … This is aptly named the pass-the-hash attack . To stop such things we just need to disable the account settings which allow such behaviour.

There is also the relay attack, which is merely the sending of packets to different computers - this could either be a full diversion , if we are on the device - or simply taking the packets we manage sniff and copying them over to another device. Relay attacks can happen when we are looking to capture RFID cards, we use a device to capture the signal and send it our laptops to be processed onto our cloned card. In the next chapter on wireless networks there is also the concept of repeating traffic or relaying, where to help our computer maintain access into a network we install a repeater like a Raspberry Pi in the network which just takes all the traffic it can sniff and sends it over to us for further examination.

NAC Bypass

I remember on my school network where it only allowed the laptops that were kept in the school to access the Ethernet . Moreover, the only way to really test this was to look at the MAC and check it was from the manufacturer that the school used - for the sake of this let’s say Toshiba. But what if I was able to spoof the MAC of the laptop ? Well, this would be bypassing only one kind of NAC - we could also :

• Employ a software client on each laptop which would communicate to the DHCP server when connecting.
• We could setup a DHCP proxy to inform relay to the NAC server - if there is , or even just ping the technician , or a new DHCP request.
• A broadcast listener which would look for ARP queries and a more general purpose sniffer if need be.
• An SNMP-trap-based approach that queries switches to determine when a new MAC address shows up on one of their connected ports.