Pentesting mDNS and Service Discovery: Exploiting Trust Assumptions

What is mDNS?

The official websites for Multicast DNS and DNS Service Discovery are more likely to confuse than clarify what these technologies are about. So before we dive into the security aspects of mDNS and DNS-SD, let’s first talk about why these protocols exist and what they actually do.

Both protocols are part of Zeroconf—a suite of technologies that lets networked devices discover each other automatically. When you send a document to print and your computer automatically suggests nearby printers, it’s most likely using Zeroconf. The protocols build on DNS, so you should at least have a basic understanding of how the DNS system works.

Normally, DNS uses unicast—each query is sent to a specific IP address. In mDNS, multicast means the query is fanned out to all devices in the broadcast domain. The term “broadcast domain” basically means all Layer 2 neighbors—for example, hosts connected through network switches. That’s important because mDNS queries don’t cross routers, since routers operate at Layer 3.

Let’s look at an example. My MacBook Pro’s mDNS hostname is MehBook.local. You can find this in the System Settings → Sharing pane.

To determine the MacBook’s IP address, we can use a DNS query tool like dig:

Note that the name ends with .local — this is a top-level domain reserved specifically for mDNS. If you see a name like that, you can probably resolve the IP address using mDNS. These domain names are called link-local names because they’re only visible within the local network.

Instead of sending a query to a DNS server on port 53, we use port 5353 and the special address 224.0.0.251—a multicast address. This specific address is reserved for mDNS. When a query goes to 224.0.0.251, every device on the local network receives a copy and can respond. In our example, my MacBook saw the query and replied with its own IP address, 10.105.0.203.

My MacBook’s IP address is dynamic—it will change over time—but its mDNS hostname stays the same. That means we can use hostnames without running a DNS server. You can see why that’s handy on home and small office networks.

What Is DNS-SD?

In the mDNS example, we looked up a device’s IP address when we already knew its name. But what if you want to reach a device whose name you don’t know—say, a printer? That’s exactly what Service Discovery is for. It lets devices advertise the specific services they offer so they can be discovered without any centralized configuration.

Let’s start by enumerating the printers:

We can use the same multicast DNS address and port, but this time we query for PTR records and use the special domain name _printer._tcp.local, which is specifically for printer discovery. In response to this query, my Brother printer returned its local hostname.

If you want to query devices for other services, check their official registry. For example, there’s the RAOP service—Apple’s AirTunes protocol. Let’s discover it:

The query shows a device on my network advertising the RAOP service — an Apple TV named “Гос­тиная” (Living Room). I actually have two Apple TVs on this network, but dig only prints the first response it receives. Fortunately, there are better tools. On macOS, use the dns-sd command from the Rendezvous (Bonjour) framework, Apple’s implementation of Zeroconf.

This command will broadcast a query and display every response it receives (press Ctrl-C to stop). Now we can see both of my Apple TVs.

On Linux, the same set of tools is provided by the Avahi package (on Debian/Ubuntu it’s called avahi-utils).

Avahi can translate service names like _raop._tcp.local into something more readable—AirTunes Remote Audio local, for example. It can also resolve the IP via mDNS, so dig isn’t needed here:`

Enumerating Devices

Now you can see why Zeroconf is appealing to pentesters: it lets you quickly enumerate a whole list of accessible devices with just a couple of queries. And Avahi goes a step further by automating the process. For example, you can realistically bundle service discovery and mDNS-based IP resolution into a single step.

As a result, we get the local hostname, IP address, and port (tcp/515—the default port for the Line Printer Daemon), plus lots of information about the printer’s capabilities in the txt field.

The command we used here is a great way to enumerate all devices of a specific type, but Avahi can do even more. The next command lists all service types at once.

Finally, Avahi can passively listen for Zeroconf (mDNS/DNS‑SD) queries from other devices, enabling background device discovery.

You can use either command together with --resolve to get the IP addresses and ports for each device—your whole network at a glance.

And of course, it’s worth mentioning that Nmap can enumerate Zeroconf devices using the broadcast-dns-service-discovery script.

This script isn’t included in the default category — you can only find it under safe.

Exploitation

Okay, device discovery is cool and all, but is there anything we can actually exploit? We found a bunch of printers and an Apple TV—now what?

First, keep in mind that home and small office network gear that relies on Zeroconf is very likely to have misconfigurations and vulnerabilities. One simple example: if a printer authenticates against an LDAP server and that server still uses the vendor’s default password, you can compromise the server, trick the printer into connecting to it, and steal the printer’s LDAP credentials. That way you can pretty quickly take over a domain account!

Second, from a security standpoint Zeroconf is similar to ARP: it assumes the local network is trusted. As we’ve already seen, Zeroconf doesn’t provide confidentiality—you can passively sniff all DNS-SD queries on the LAN. There’s no authentication either: any device on the network can respond to mDNS or DNS-SD queries. As a result, an attacker can, for example, answer queries with misspelled names (which a real domain would simply ignore). And for correctly formed queries, they can try to beat the legitimate device to the punch and advertise services that don’t actually exist.

If you’re not familiar with Responder yet, now’s the time: it’s a fantastic tool for local network spoofing (cache poisoning). In addition to mDNS, it responds to NetBIOS and LLMNR queries, making it ideal for penetration testing.

I’m starting Responder on the machine I’ll use to launch the attack.

Responder sits and waits for any device on the network to make a request. I trigger that request from the victim machine: I try to look up my MacBook’s IP address but “accidentally” mistype it.

Note: even with a typo in the hostname, I still get a response. The Responder logs show it was the one that replied—and it redirected the victim to the attacker’s machine.

What if the victim sends a real, correctly spelled hostname? In that case, Responder tries to beat the legitimate device and reply first. For example, here I’m resolving my printer’s name.

The first result is the real printer’s response. The second, which arrived almost 1.2 seconds later, is a poisoned response from Responder. Most clients accept only the first response and ignore any subsequent ones, so in this case Responder didn’t succeed.

Conclusion

Zeroconf is a solid, widely available technology. You’re probably already using it at home or at work, even if you don’t realize it. Pentesters can leverage Zeroconf for quiet—or even background—device discovery. While scanning with Nmap generates lots of traffic and highly distinctive signatures, Zeroconf-based discovery uses very little traffic and blends in with normal network activity. On top of that, mDNS poisoning with Responder is a much more reliable way to pull off a man‑in‑the‑middle attack than classic ARP poisoning.