Over a decade ago, I worked on a system that would walk network switches/switch ports, log what macs were in what ports, and use this data to turn off switch ports to isolate systems from the corporate network. This might be due to a virus alert, reports indicating an unpatched system, or any other situation that may require isolation.
Fast forward a few years, and lots of experience, later and I had a question: “What happens if a computer has a MAC address of the broadcast, NULL, or other reserved address?” When I went looking, I was unable to find any publicly available research results.
I decided to test it myself by making a virtual interface on my Linux box. Initially, the results seemed that Linux and other OSs would not allow it. Thus, my curiosity was temporarily squashed and other important things kept me busy for a couple more years.
Enter COVID; more free time, more time to play. And I found out the answer was significantly more nuanced than my initial, simple test indicated.
Playing with MACs
There are a lot of interesting questions to ask when starting to play with MAC addresses on the network.
Will the switch inspect the MAC/IP combo, and make sure it is valid for some Protocols? This would require the switch to be smart and necessitates frequent updates.
Would the switch add the entry to its ARP table? If it does, this could really break the network, as it would then send broadcast addresses to a single port. Alternatively, it may have special logic to add it to a table, but then ignore it. Both options are interesting and could make it very difficult to track down on a network.
If you used a reserved MAC, could you just become another IP on the network without anyone knowing? This could make the defense blind to your actual activity, and get them chasing ghosts, as they are analyzing clean boxes looking for patterns to try and track attackers, while the real attacker box remains unexamined.
How would different OSs handle these corner cases and is it plausible to even talk to them? The attack is worthless if the OS ignores it.
How would the router handle these corner cases? Are you limited to local network, or can you use this all around the network?
Now the big question is how do we test this if the OS does not allow it? Enter gopacket, a relatively simple and speedy library in Go to help rewrite packets for Golang.
Some of you may ask "Why not Scapy?" and the short answer is that many moons ago I needed to sniff and spoof network traffic and win a race condition. I was never winning in Python with Scapy, so I learned gopacket and never went back.
Creating gitn, a MAC/IP spoofer
Using Golang, I created a MAC and IP spoofer tool called GhostInTheNetwork, or gitn for short. available at https://gitlab.com/attackresearch/GhostInTheNetwork. This spoofer lets you define IP, MAC, interface, and destination MAC (think router). It does this by creating a TUN device and rewriting all data to and from the device so that any normal traffic can go over it. It will continuously ARP, and handle ARPs so that everything is sent over the switches correctly.
To be clear, I’m not claiming that it is a production tool. It is in fact an experimentation tool meant for educational purposes only, though it has been stable enough for me to use for various tests. I used it to test from Linux and macOS; it might work on Windows as well given that it is Go, but I didn’t try.
Let’s get testing!
The first thing to note is I’m not rich and the company small so we can’t afford to try every possible combination of switch/router. In the end, testing was done on Cisco small business switches, a Ubiquiti soho switch, a Ubiquiti dream station router, and a Linux (older kernel now) firewall/router.
As far as OSs that will receive and respond to the crafted packets, I was able to test all the major ones. My primary work machine is a Mac. I also have Linux machines and VMs for a variety of tasks as well as a Windows box for gaming and occasional tests where an ARM Windows VM just won’t do.
Will the switch inspect the MAC/IP combo, and make sure it is valid for some Protocols?
If the switch inspects everything, the rest of these questions become irrelevant. Since you’re reading this, you likely can guess.
Switches don’t care in the least that you use reserved MACs with regular IPs.
You do have to ARP during the initial connect, as OSs don’t just trust your MAC address and send back to it. The beautiful part of this is that if you ARP poison a box with the broadcast, the original host will still get their traffic, so anyone reviewing network traffic won’t notice ;).
In the above screenshot we can see the broadcast MAC which we have set as our MAC address asking the broadcast MAC for the MAC address of the IP address 192.168.128.4 and 192.168.128.4 responding to the broadcast MAC with the answer. This means we can now play around with reserved MAC/IP combos and answer more interesting questions.
Would the switch add the entry to the ARP table?
This is what really started exciting me. The switches we tested did not record the fake MAC/IP in the ARP table, or anywhere that we could find.
For initial testing both NULL and Broadcast were used, but there are others that were not tested, such as multicast. The behavior of not recording MAC/IP makes sense, since being in the ARP table could cause all sorts of crazy behavior if broadcasts were all sent to one port on the switch.
It also makes tracking down a rogue actor very difficult. Even figuring out the technique in use will be complicated.
We can see above that even though we took the 192.168.128.69 IP address, it doesn’t show up in the ARP tables at all when using the broadcast address. Null will show up but will not record the IP correctly.
If you become a reserved MAC, could you just become another IP on the network without anyone knowing?
This may seem similar to the last question, but it isn’t.
This is purposefully using ARP to claim we are the broadcast MAC even though a system is already in the switches’ ARP tables.
When I started this experiment, it was completely unknown how the switch would handle this case. Would it see the new IP on the wrong port with the broadcast and delete the original entry, effectively killing a lot of the traffic to the real port? Or would it keep the original entry and since the second entry was to the broadcast, just let both machines with the same IP exist in the switch network? Or something else entirely?
For all the switches we tried, the switch itself will be more than happy to let the 2 IPs exist on the network, which is great for us, because we will not cause disruption.
How would different OSes handle these corner cases, and is it plausible to even talk to them?
This is really where the rubber meets the road, and we see if we can really do something cool with this. So, for all of these tests, we were coming from a Linux box and using the new gitn tool to become various MAC/IP combos to talk to different platforms to see how they will respond.
macOS
Much to my dismay, the first test talking to an macOS box using the broadcast MAC and Null MAC the addresses were ignored… This was a little bit worrisome and strange as even tcpdump wouldn’t see the ARPs come in.
Linux and Windows
The story here is different. In both of these cases, the machines would respond to the Broadcast and Null MAC addresses that were being used by the attacker. If you use the Broadcast MAC, normal traffic will not even be interrupted. This is because the other machines on the network still get the TCP/IP packets because they are being broadcast to everyone.
Below is an example where we can see the attacker make a connection with the broadcast. The real host connects from its MAC address and the response goes to the broadcast, even though it originally comes from a real MAC address.
One nice thing about spoofing a Windows box's MAC/IP is that an IP conflict message will not be displayed to the user. It also appeared as if the Windows box does not attempt to reset the connection when it receives unexpected packets. This means that your connections won’t get reset if you steal a Windows boxes’ IP/MAC. Windows is also happy to chat with the broadcast MAC as seen below.
It should be noted that bad timing may result in a failed connection. I did not experience this in my testing, but in theory, if the real client wins the ARP race you may not get your traffic. A small price to pay for stealth.
How would the router handle these corner cases?
Like so many things, it seems to depend a lot on your setup. The Ubiquiti router dropped the packets with NULL, multicast, and BROADCAST MAC addresses, but faking a MAC on the network will work fine, as long at the IP is unique. You can even reuse an IP on the network as long as the computer that you're stealing the IP from has a DROP rule in its firewall so that it will not send resets.
One interesting thing about the Ubiquiti testing is that when I stole a MAC from a wireless system and just a random unused IP on the network, it didn’t show up anywhere in Ubiquiti interface. I am guessing this is due to the MAC collision between the two sides but would be worth further investigation.
As seen below, even though 192.168.128.70 is actively communicating, it is not showing up in the list of connected devices at all, as it is using the MAC for 192.168.128.89 on the wireless. Claiming another MAC from the wired side did cause the two systems to fight for the port and cause some traffic loss.
With a Linux firewall/router, by default, it will gladly pass that traffic for you to the outside world. Below you can see the broadcast MAC talking with the firewall, and the firewall completing the connection.
Cool, questions answered, now what?
This ends up being an interesting tool to use if you are on a true red/blue type engagement. When you need to scan to find a target to move to, or really need to do something that is likely to generate logs and trigger alerts, you can deflect attention and keep the opposition looking in the wrong places.
If you’re really clever (and kinda evil), you might even be able to get the blue team to hurt themselves. Pretend to be the IP of the Splunk collector, IDS, or if you are particularly feisty, the Active Directory server. Sow complete chaos while you just move around in the network on boxes that aren’t as closely monitored and are less likely to pull the attention away from the boxes you were spoofing.
Another reason this can be interesting is, using a stolen IP and Broadcast MAC, you may be able to get around firewalls on the network. In general, bastion hosts are a great idea, but if you are on the same network as the bastion host, you might be able to bypass it and talk to firewalled off systems.
A side effect of this tool is that you can also become the MAC/IP address of another host on the network. This isn’t much different than creating a virtual interface with macvlan in Linux and then ARP flooding the MAC address of the system you’re becoming. I will sometimes still end up using gitn for this just because it has the ARP flooding built in for you.
Looking to the future.
There are a couple of things to investigate.
I was playing with NULL and BROADCAST primarily, but there are a good number of reserved MACs out there, they may have other cool effects.
Are there corner cases with firewalls? Can you maybe bypass some restrictions by fooling them into thinking you’re something that you’re not?
What about becoming restricted IPs like multicast, localhost, etc.? Is there anything fun there? I played a bit with localnet without luck, but there still could be more.
Testing on other hardware. Lots of switches and routers out there.
Adding other protocols like ipv6.
Playing with c2 on made up protocols on these networks.
Seeing if gitn works on Windows and changing it if needed.
Wrapping it all up.
Using the Broadcast MAC can be a powerful tool to hide, misdirect, and get around obstacles inside a network. The Broadcast MAC is used in a similar manner to ARP spoofing to sniff traffic, but without being a MITM.
The defense should be aware that tools like gitn are possible and should think about that when reacting to an incident. One of the biggest takeaways is that this might not show up in the switch/router logs or topography and you should inspect the ARP tables of the machines being investigated for odd entries.
If you would like to play with gitn it is available at https://gitlab.com/attackresearch/GhostInTheNetwork. It supports a '-h' option for help and has a documentation in the git repo as well.
If you have questions about the tool the best way to hit me up is via DM on Twitter.
~Kaylee