The next network vulnerability
that we're going to discuss
involves the Link-Local Multicast Name Resolution protocol,
known more commonly by the abbreviation LLMNR.
The LLMNR protocol
is based on the DNS packet format,
and it allows both iPv4 and iPv6 hosts
to perform name resolution on the host
if they're on the same local lake.
This means that both hosts
need to be on the same internal network
to be able to use the Link-Local Multicast Name Resolution.
If there is not a DNS server on the network,
then your Windows machines can use LLMNR
to determine the names and the IP addresses
of the other servers and resources on that network.
If the systems are running Linux though,
LLMNR is not going to work.
Instead, Linux systems rely on ZeroConf,
which uses the SystemD, or system Damon,
and the system resolve D Damon
to accomplish the name resolutions on their local links.
ZeroConf and LLMNR
are useful for creating temporary networks
like ad hoc Wi-Fi networks,
Bluetooth networks, and things of that nature.
Another type of name resolution protocol
that we can exploit is known as the NetBIOS Name Service,
also known as the WINS service on a Windows system.
Now, the NetBIOS Name Service,
which is usually written as NBNS or NBT-NS,
is part of the NetBIOS-over-TCP protocol suite
that's used as a type of name resolution
inside of the internal network
to translate internal names to IP addresses
using a 16 character ASCII name.
The NetBIOS Name Service
is implemented in both the Windows operating system
as well as the Linux operating system.
Now the NetBIOS Name Service
is going to use the host name of a system.
For example, Jason's PC,
and it's going to use that to resolve it.
This allows us to be able to connect
to a resource using the server's name
instead of using its IP address.
For example, if you've ever tried to connect
to a network server
and you entered something like //FileServer or //ShareDrive,
you are actually using the NetBIOS Name Service
to identify the proper IP address behind the scenes
and then connect to that resource.
By default, Windows machines will first attempt to use
the Link-Local Multicast Name Resolution, or LLMNR,
but if that fails, then it's going to attempt to use
the NetBIOS Name Service, or NBT-NS instead.
Now to exploit the Link-Local Multicast Name Resolution
or the NetBIOS Name Service,
a penetration tester can use a tool known as responder.
Responder is a command line tool in Kali Linux
that's used to poison the NetBIOS, LLMNR,
and mDNS name resolution requests.
This is considered a post exploitation tool
because you first have to break into that local area network
in order to use this tool.
So for example,
let's say you've broken into a Windows network,
you can now use responder
to poison the Link-Local Multicast Name Resolution process
for name resolution inside of that network.
When you run responder,
it's going to start listening for any time
a system calls out
for a certain machine,
and then it's going to poison the name resolution call
by sending back incorrect information.
So let's say that a Windows machine
is trying to find the file server
and it sends out a resolution request
using the LLMNR protocol.
Now responder is going to see this request
and then it's going to respond to it
with the IP address of a file server
that's controlled by that penetration tester.
When this IP address is returned to the Windows client,
it's then going to try to connect
to the attacker's controlled file server
instead of the company's real file server.
From this position,
we can perform other attacks and exploits,
or even use this LLMNR poisoning
to conduct an on-path attack
by putting our attack machine
in the center of all the communications
between the client and the server that we want to victimize.
Now for this attack to work though,
the attacker has to be able to prevent the real file server
from responding to the initial LLMNR request.
In a real attack or hack,
this could easily be done
by temporarily kicking that server offline
using a denial of service attack.
But for our engagements,
that's likely not going to be in your scope
of allowed activities.
So instead, you're going to want to try to trick the victim
into querying a non-existent name
by using some kind of social engineering.
For example, you might send a phishing email
that has a link to the local share drive
that says //FileServers with an s
instead of //FileServer without an s.
If the victim tries to open that link
to connect to the file server,
they are now going to be rerouted
and redirected to your attack server instead
because you have poisoned that LLMNR using responder.