Linux

MAC Me Up Before You Go-Go: Spotting Rogue Devices Without Installing 400 Python Dependencies

Keystone Collective

— 16 min read
MAC Me Up Before You Go-Go: Spotting Rogue Devices Without Installing 400 Python Dependencies
Photo by Avi Richards / Unsplash

There’s a certain breed of “cybersecurity enthusiast” who believes enlightenment lies somewhere between installing Arch Linux and setting their terminal background to a gradient of anime characters. They’ll spend six hours customising their Zsh prompt to display Unicode cows and still can’t tell you the difference between a MAC address and a Big Mac.

Today, we’re going to fix that. We’re not installing another dependency. We’re not cloning anything from GitHub that calls itself “mac-vendor-pro.” We’re going to do something truly subversive: use the tools that are already built into Linux. You know, that dusty old operating system underneath your 47 shell themes. Yes, yes, GNU/Linux if we’re being pedantic, the kernel and the utilities holding hands under a beige terminal window. Either way, it’s what’s doing all the real work while you’re busy configuring neofetch to show a catgirl in ASCII.

And in the process, we’ll go from a humble little one-liner to a basic form of anomaly detection that even a hardened sysadmin would begrudgingly respect.

A Brief History of the MAC Address: The Original Digital Nametag

Let’s rewind a bit, before we start writing Bash functions that make us feel clever.

The MAC address, that’s Media Access Control, not Macintosh, calm down, was born out of a simpler time. The early 1980s, when Ethernet cables were thick enough to double as self-defence weapons and “the cloud” was just an ominous thing over your data centre.

The whole idea came out of work at Xerox PARC, the birthplace of Ethernet, where people like Robert Metcalfe and David Boggs were trying to make computers talk to each other without physically colliding on the same wire, an oddly relatable struggle, really (Metcalfe and Boggs, 1976). Their early Ethernet experiments needed a way for every network interface to have its own unique identity, so packets wouldn’t just end up in the void. That’s how the MAC address was born, a permanent, globally unique serial number etched into every network interface card (NIC).

Later, the IEEE (Institute of Electrical and Electronics Engineers) formalised Ethernet and the MAC addressing system under its 802.3 standard (IEEE, 2022), while the ISO (International Organization for Standardization) came up with the Open Systems Interconnection (OSI) model, that famous seven-layer cake of networking theory that haunts every networking exam. MAC addresses live at Layer 2: the Data Link layer, where devices exchange frames and politely pretend collisions don’t happen (China and Goodwin, no date).

Basically, it is that bit responsible for getting frames of data between devices on the same local network segment. It doesn’t care about IP addresses, subnets, or routing; that’s all higher up the chain. The MAC is just a handshake between neighbours:

“Hello, I’m 00:10:FA, nice to meet you, please don’t flood the network.”

A MAC address is 48 bits long, that’s twelve hexadecimal characters, and is usually written in colon-separated pairs, like 00:1A:2B:3C:4D:5E. The first half, the Organisationally Unique Identifier (OUI), tells you which company manufactured the device. The second half is the device’s unique serial number, assigned by that vendor.

So 00:1A:2B isn’t just random gibberish; it tells you who made the hardware. The 00:1A:2B prefix might map to Cisco, Dell, or perhaps that obscure Shenzhen startup whose routers like to phone home.

In theory, this design gave every device a unique hardware address, your network card’s digital birth certificate. In practice, it also created a new form of forensic gold: every packet now carried a trace of its manufacturer, like a brand logo burned into the network layer. Back in the early days of Ethernet, that was just neat engineering. Today, it’s intelligence.

Of course, in the 21st century, nobody leaves anything sacred. With virtual machines, MAC spoofing, and Wi-Fi privacy randomisation, this supposedly permanent address has become more of a polite suggestion than an immutable truth. But even now, that prefix, those first six hexadecimal digits, remain one of the simplest, fastest ways to fingerprint a device’s origin.

In short: the MAC address is your device’s network nametag, sitting squarely in Layer 2 of the OSI stack, introduced by the IEEE so your packets could find their way home. It’s the oldest trick in networking, and somehow, forty years later, still one of the most useful.

Fun Fact: The Magic of MACs (Literally)

Just when you think MAC addresses are boring, static little identifiers scribbled onto network cards, along comes a feature that turns them into digital resurrection spells.

It’s not a Hogwarts spell, but it might as well be. The Wake-on-LAN, a technology that lets you power up a machine remotely by sending it a single enchanted packet of data. Officially, it’s called a Magic Packet™ (yes, trademark and all, AMD coined the term back in 1995). Unofficially, it’s the IT equivalent of whispering the true name of a machine until it rises from the dead.

Here’s how it works: a network card in “sleep” mode keeps just enough power to listen for a specific broadcast. The moment it hears a frame filled with six bytes of FF followed by its own MAC address repeated sixteen times, it jolts awake and boots the system. No IPs, no credentials, just good old-fashioned Ethernet voodoo (AMD, 1995).

It’s one of those ancient, beautiful hacks that remind you how much elegance and insanity coexist in network engineering. On the bright side, it makes remote maintenance a breeze. On the slightly spooky side, it means that even when your machine is “off,” there’s still a tiny sliver of silicon waiting patiently for its name to be called.

Bash Before Python: Writing a Function Like a Real Sysadmin

Before we dive into the weeds, let’s establish a core principle: if your first instinct when solving a problem is to install a Python package, congratulations, you’re part of the reason sysadmins drink before lunch.

Here’s the radical idea: instead of downloading half of PyPI to find out who made a network card, we can just use Bash and awk. Yes, that thing you’ve been avoiding since 2009.

Imagine you’ve got a simple CSV file listing MAC prefixes and vendor names (maclookup.app, 2025), something like this:

macPrefix,vendorName
00:00:0C,Cisco Systems Inc.
00:05:02,Apple Inc.
00:06:C1,Cisco Systems Inc.

Now we’ll write a bash function that looks up the manufacturer of any MAC address you feed it:

macvendor() {
    local db="/path/to/mac-vendors.csv"  # Path to CSV mapping OUIs/prefixes to vendor names. Update this to your actual CSV or export an alternate path.
    local mac="$1"
    local prefix vendor

    if [[ -z "$mac" ]]; then
        echo "Usage: macvendor <MAC address>"
        return 1
    fi

    prefix=$(echo "$mac" | tr '[:lower:]' '[:upper:]' | tr '-' ':' | cut -d: -f1-3)
    # Normalize both the CSV prefix and the input prefix by removing separators
    # (colon, dash, dot) and uppercasing before comparing. This allows matching
    # CSV entries like "aa-bb-cc", "aa:bb:cc", "aabbcc", or lowercase variants.
    vendor=$(awk -F',' -v pfx="$prefix" '
        BEGIN { pfx=toupper(pfx); gsub(/[:.\-]/, "", pfx) }
        { cell=$1; gsub(/[:.\-]/, "", cell); if (toupper(cell)==pfx) { print $2; exit } }
    ' "$db")

    if [[ -n "$vendor" ]]; then
        echo "$vendor"
    else
        echo "Unknown Vendor for prefix $prefix"
    fi
}

Save that into your .bashrc, reload your shell, and voilà, you’ve got a new trick up your sleeve.

Run:

macvendor 00:05:02:DE:AD:BE

Output:

Apple Inc.

Congratulations, you’ve just built something useful in under two minutes, without installing anything, without a single emoji, and without compiling a dependency tree that could double as a family curse.

Think Like a Sysadmin, Not a YouTuber

Now, I can already hear the chorus of distro-hoppers in the background:

“But can we make it display vendor logos in ASCII?”

No. No, you cannot.

This is where you stop thinking like a theme collector and start thinking like someone responsible for an actual network. You’re not configuring a spaceship cockpit; you’re defending a system that, if it goes down, means people can’t work, invoices don’t send, and some poor intern will spend their afternoon trying to explain what “DHCP exhaustion” means to management.

A sysadmin doesn’t care if your terminal can render emojis in true colour. They care whether the switch just spawned three new MAC addresses from an unknown vendor at 3 a.m.

See, this is where the mindset shift happens. You start realising that cybersecurity isn’t about “cool tools”, it’s about awareness. Bash and awk may not get likes on Reddit, but they’ll tell you when someone’s snuck an IoT camera onto your Wi-Fi. They’ll reveal the printer that suddenly started doing HTTPS traffic. They’ll quietly rat out that “smart fridge” that joined the guest VLAN on its own initiative.

Because when you think like a sysadmin, you stop treating your Linux machine as a fashion accessory and start treating it as a scalpel. You start using native utilities as diagnostic instruments instead of shiny toys. You stop watching “10 Things to Do After Installing Ubuntu” videos and start muttering “why is that MAC address changing every five minutes?”

And that, in essence, is the difference between the hobbyist and the professional. The hobbyist asks, “Can I theme it?” The sysadmin asks, “Can I trust it?”

Every MAC vendor tells you something about your environment. Seeing “Hewlett Packard” and “Dell” is normal. Seeing “Xiaomi Communications” on your office LAN might be a sign that someone plugged in a random gadget from home. Seeing “Espressif Systems” (the folks behind those cheap Wi-Fi chips) could mean a homebrew IoT sensor, or something far more suspicious.

That’s not paranoia, that’s context. The kind of context that separates a tinkerer from someone who can spot a breach before it becomes a headline.

And yes, let’s be realistic: this whole exercise is mainly for educational purposes or for managing small networks, your home lab, your small office, that café Wi-Fi you regret offering to “help” set up. Big organisations have budgets, automation, and monitoring suites so advanced they make our Bash scripts look like something Linus Torvalds would throw at you in a code review just to watch you cry. But that’s the point: learning these basics is how you understand what those big tools are doing under the hood. And understanding is what turns a script-kiddie into an actual security practitioner.

A Brief Tour of Device Profiling Without Breaking a Sweat

You don’t need enterprise-grade network management tools to start building a basic inventory. Fear not, you're fully armed: Bash, awk, and the astonishing restraint not to install every shiny thing on the internet.

Let’s say you want to scan your network for all active hosts and map their vendors and then for each IP that responded, grab the MAC address and vendor:

#!/bin/bash

# Simple LAN map
# Requires: macvendor() function defined in your shell and mac-vendor.csv

# Clear previous results
outfile="/tmp/live.txt"
> "$outfile"

echo "[*] Scanning for live hosts..."
for ip in $(seq 1 254); do
    ping -c1 -W1 192.168.1.$ip &>/dev/null && echo "192.168.1.$ip" >> "$outfile" &
done

# Wait for all background pings to finish
wait

echo "[*] Mapping MAC addresses and vendors..."
printf "%-15s %-18s %s\n" "IP Address" "MAC Address" "Vendor"
echo "--------------------------------------------------------------"

while read -r ip; do
    mac=$(ip neigh show "$ip" | awk '{print $5}')
    if [[ -n "$mac" ]]; then
        vendor=$(macvendor "$mac")
        printf "%-15s %-18s %s\n" "$ip" "$mac" "$vendor"
    fi
done < "$outfile"

Output might look like this:

[*] Scanning for live hosts...
[*] Mapping MAC addresses and vendors...
IP Address      MAC Address        Vendor
--------------------------------------------------------------
192.168.1.1     00:06:C1:AA:BB:CC  Cisco Systems Inc.
192.168.1.22    00:10:FA:DE:AD:BE  Apple Inc.
192.168.1.55    38:2C:4A:12:34:56  Espressif Systems (Shanghai)

That last one? Probably an IoT device. Maybe your smart plug. Maybe your neighbour’s “spy lamp.” Either way, you’re already starting to see why this data matters.

The Cybersecurity Angle: When Curiosity Turns into Defence

Knowing who’s on your network isn’t just tidy, it’s defensive awareness. MAC vendors are a form of fingerprinting. They tell you who built the hardware. Combine that with where it’s plugged in, and you’ve got a powerful way to spot intrusions, misconfigurations, and plain old weirdness.

Let’s say your baseline network consists mostly of Dell laptops and Cisco switches. One day, you spot a new prefix:

B4:E6:2D  →  Xiaomi Communications Co., Ltd.

Why is a smartphone vendor suddenly on your office VLAN?
Either someone’s tethering their phone, or you’ve got a rogue access point. Both are worth a raised eyebrow and a quiet sigh.

This is how anomaly detection starts, not with an AI model in the cloud, but with an observant human and a bit of Bash.

And this isn’t hypothetical. In practice, IT teams regularly stumble across unregistered wireless gear during routine network surveys. A surprising number of these devices weren’t bought through official channels, don’t appear on any asset register, and are broadcasting insecure SSIDs. Most of them aren’t malicious; they’re the product of one well-meaning academic trying to get Wi-Fi in the corner of a physics lab where signal goes to die. But that kind of improvisation can open an entire subnet to the world.

In one (anonymised) case, a manufacturing network noticed an unusual traffic spike traced back to a device whose MAC looked like it belonged to Espressif Systems, cheap microcontroller hardware often used in DIY IoT projects. On inspection, it turned out to be a small rogue Wi-Fi bridge tucked under a desk, quietly relaying internal traffic externally. Whether it was malicious or just an overenthusiastic engineer experimenting with home automation, the MAC prefix was the clue that led to the root cause.

That’s the power of curiosity with context. The same awareness that starts as “Huh, what’s that vendor?” can evolve into “Why is that even here?”, and that’s how defenders win. You don’t need to run a full intrusion detection system to notice when something smells wrong. You just need to know what “normal” looks like, and have the presence of mind to check when something isn’t.

This is why tools like macvendor aren’t just geeky party tricks. They’re foundations of situational awareness. When you understand the fingerprints on your network, you stop waiting for an alert and start thinking like one.

Spotting the Odd One Out

Let’s take it a step further. Imagine you run the script daily, saving each run as a log. Then you can compare today’s vendor list to yesterday’s.

macvendor $(ip neigh | awk '{print $5}') > today.txt
diff yesterday.txt today.txt

Suddenly, you’ve got a simple change tracker. New vendors? Flag them. Missing ones? Check if something’s unplugged or powered off. This is poor man’s asset monitoring, but it works.

Even better, you can wrap it with a bit of logic to scream when something looks odd:

#!/bin/bash
known_vendors=("Cisco Systems" "Dell" "HP" "Intel" "Apple")
macs=$(ip neigh | awk '{print $5}')

for mac in $macs; do
    vendor=$(macvendor "$mac")
    match=false
    for kv in "${known_vendors[@]}"; do
        [[ "$vendor" == *"$kv"* ]] && match=true
    done
    if ! $match; then
        echo "[ALERT] Unknown vendor detected: $vendor ($mac)"
    fi
done

Example output:

[ALERT] Unknown vendor detected: Espressif Systems (38:2C:4A)
[ALERT] Unknown vendor detected: TP-LINK TECHNOLOGIES CO., LTD. (F0:B4:29)

You're now doing anomaly detection, the thrilling art of chaos. No Elasticsearch. No containers. Just you, a bunch of text files, and your borderline obsessive hatred for anything resembling “modern infrastructure.” It’s messy. It’s raw. It’s pure, unfiltered logic, and you love it.

Beyond Vendors: More Ways to Catch Weird Devices

If you’ve caught the scent of sysadmin bloodlust, you can expand this concept easily. The vendor is just one fingerprint. Others include:

  • The hostname (see if it suddenly changes from “Dell-Laptop” to “raspberrypi.local”).
  • The open ports (nmap is your friend).
  • The protocols it uses (your “printer” shouldn’t be running SSH at 3 a.m.).
  • The activity schedule (if something is online only at night, it’s either a vampire or a compromised IoT device).

Run these checks occasionally, and you’ll start noticing when something’s not quite right, long before the SIEM dashboard starts blinking red. Because the truth is, many security incidents aren’t detected by magic; they’re noticed by someone who simply knows what belongs.

And here’s where it happens, the turning point. You start with a Bash one-liner to check MAC vendors, and before you know it, you’ve got a folder full of scripts with names like netwatch.sh and weirdoscan.py. You tell yourself it’s “just for testing,” but then you’re parsing ARP tables, storing results in SQLite, visualising anomalies in Grafana, and suddenly you’ve built a lightweight network monitoring suite that rivals the one your employer pays £40,000 a year for.

This, by the way, is the sysadmin rabbit hole. It starts innocent, “I just want to see who’s connected to my router”, and ends with you learning about SNMP, writing your own cron jobs, and ranting about subnet hygiene to people who didn’t ask. One day you wake up and realise you’ve memorised all your colleagues’ laptop MAC prefixes by heart and can identify them by Wi-Fi beacon traffic alone.

The thing is: that’s good. That’s how it starts.

Because every tool worth using began as someone’s homebrew hack.
Nmap? Originally a hobby project. Wireshark? A university tool to debug packet loss. Metasploit? Just a scripting framework that got very out of hand.

When you start automating your own small tasks, when you look at a list of IPs and think, I could make this prettier, faster, more useful, you’ve crossed from user to builder. And that’s when cybersecurity stops being “a topic” and becomes a skill.

You’ll discover that the rabbit hole isn’t dark, it’s beautifully illuminated by the glow of terminal windows at 2 a.m., each one teaching you a new layer of how networks really work.

Soon you’ll learn to correlate MACs with DHCP leases, sniff ARP requests with tcpdump, maybe even craft your own mini-intrusion alerts using nothing but Bash and spite. Before long, you’ll have built your own weird, janky, but entirely functional toolkit, one that fits your environment perfectly because you wrote it for yourself.

That’s what proper sysadmins do. They don’t just install tools; they grow them.

And it all begins with one simple idea:

“What’s that MAC address doing there?”

A Side Note on Randomised MACs

MAC address randomisation (Henry and Lee, 2025), that charming privacy feature that keeps you safe from over-eager advertisers and, as a delightful side effect, keeps sysadmins mildly confused before breakfast.

In the old days, a MAC address was like a digital birth certificate, unique, permanent, and proudly stamped with the manufacturer’s name. You could look at a prefix and instantly know whether it was a Dell laptop or a £9 router from an online bargain bin. Then came the age of privacy-conscious devices, and suddenly half your network started showing up under witness protection.

Randomisation isn’t bad, quite the opposite. It stops your phone from being tracked across Wi-Fi networks, spares users from invasive analytics, and generally makes the surveillance economy’s job a bit harder. The only downside is that it also makes your network map look like it’s being run by a committee of ghosts.

Here’s what’s actually happening. Every MAC address has a little flag in its first octet that says whether it’s globally assigned or locally generated. When that “locally administered” bit is set, the device is basically saying, “I made this up myself, don’t bother checking the vendor registry.” You’ll often see those starting with 02:. Some systems randomise just when they’re scanning for Wi-Fi, then use their real hardware MAC once connected. Others randomise per network, so they look consistent to one router but not to others. And a few, bless them, randomise every session, every boot, every breath, just to make sure you never get too comfortable.

If you want to see which of your network’s inhabitants are wearing disguises, here’s a quick check. It looks at that locally-administered bit in the first octet — the telltale sign of a made-up address:

# One-liner: tag MACs from ip neigh as LOCAL or OUI

ip neigh | awk '{print $5}' | sort -u | while read m; do \
  fo=${m%%:*}; if (( (0x$fo & 2) == 2 )); then printf "%s LOCAL\n" "$m"; else printf "%s OUI\n" "$m"; fi; \
done

If you start seeing “LOCAL” pop up everywhere, that’s not a sign of trouble, just a reminder that users (and operating systems) finally care about privacy. For network admins, it means your vendor lookups get a little fuzzier and you’ll need to lean more on authentication, DHCP logs, and behavioural patterns rather than raw MAC prefixes.

So yes, randomised MACs may make your spreadsheets messier, but they also make tracking people without consent harder, and that’s a trade-off worth a few extra awk commands.

Because at the end of the day, privacy isn’t the enemy, complacency is. And if a bit of randomisation keeps us honest, that’s probably the best kind of chaos we could ask for.

A Sysadmin’s Closing Thoughts

If there’s one moral to take from all this, it’s this: cybersecurity doesn’t start with fancy tools; it starts with awareness.

You can distro-hop all you like, install every Python framework under the sun, and still miss the rogue device that’s been sitting on your network for a week because you never bothered to check the ARP table. Stop worrying about emojis in your terminal prompt. Start worrying about who’s actually connected to your network.

There’s something deeply satisfying about catching an unauthorised gadget using nothing more than Bash and cynicism. It’s like outsmarting an intruder using a butter knife, inelegant, but devastatingly effective.

But let’s talk about the bigger picture for a moment.

We live in an age where “learning tech” often means watching YouTube tutorials on how to install plugins for someone else’s pre-made tools. It’s all surface, no substance. Every new video promises to make you “10x more productive” or “hack your workflow,” when what you really need is to get your hands dirty.

Because that’s what the people who built this field did. They broke things, rebuilt them, misconfigured networks, accidentally took down the office switch, and learned from it. They weren’t afraid to fail, they just did it quietly, at 2 a.m., in a cold server room that smelled faintly of dust and despair.

If you’re new to cybersecurity, do yourself a favour: stop watching the fifteenth video about making your terminal look like a neon unicorn vomited on it. Instead, open your router’s admin page. Sniff your ARP cache. Run tcpdump and stare at the raw packets until your brain starts connecting the dots between MAC addresses, IPs, and protocols.

Yes, it’s messy. Yes, it’s confusing. That’s the point. That’s how you learn.

Because there’s a kind of learning that doesn’t come from tutorials, it comes from frustration, repetition, and small victories. The first time you recognise a rogue MAC address in your logs, it’ll feel exactly like your granddad finally getting that 60-year-old car engine to turn over in the barn. Greasy hands, tired eyes, but pure satisfaction.

That’s what the “old school” sysadmins understood. They didn’t need YouTube thumbnails or “productivity hacks.” They had manuals, intuition, and curiosity. And when something didn’t work, they didn’t reinstall Ubuntu, they fixed it.

So here’s the advice to the next generation of tinkerers and defenders: Don’t chase aesthetics. Chase understanding. Learn how things actually work, from the MAC layer up. Know what an ARP table looks like, what a broadcast storm feels like, and how to spot when your network’s behaving “off.” Learn to troubleshoot without Googling it immediately. Learn to love command-line tools that don’t sparkle.

Because in the end, cybersecurity isn’t about the gear you install, it’s about the brains you train.

So, next time someone brags about their new terminal theme, just smile, run macvendor, and quietly know that while they’re customising their prompt, you’re securing your network. Because that’s what separates the hobbyists from the sysadmins, the willingness to get your hands dirty, learn the basics, and keep the lights on while everyone else is busy adjusting their colour scheme.

References:

Metcalfe, R., M., Boggs, D.,R. (1976) 'Ethernet: Distributed packet Switching for Local Computer Networks', Computer Systems. Available at: https://www.cl.cam.ac.uk/teaching//1819/CompNet/files/p395-metcalfe.pdf (Accessed: 11 October 2025)

IEEE (2022) '802.3-2022 - IEEE Standard for Ethernet'. Available at: https://ieeexplore.ieee.org/document/9844436 (Accessed: 18 October 2025)

China, Ch., R., Goodwin, M. (no date) 'What is the OSI model?', IBM. Available at: https://www.ibm.com/think/topics/osi-model (Accessed: 18 October 2025)

AMD (1995) 'Magic packet technology'. Available at: https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/white-papers/20213.pdf (Accessed: 18 October 2025)

maclookup.app (2025) 'MAC Vendor CSV Database'. Available at: https://maclookup.app/downloads/csv-database (Accessed: 18 October 2025)

Henry, J., Lee, Y. (2025) 'RFC 9797: Randomized and Changing Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases', IETF. Available at: https://www.rfc-editor.org/rfc/rfc9797.pdf (Accessed: 18 October 2025)

Read more