Cracking the NAC
How I bypassed network access control, reached a production network, and did it all from the parking lot.
Introduction
These days, companies spend a LOT of money trying to secure their networks. One of the technologies that’s become popular is Network Access Control, or NAC.
Now, don’t get me wrong. NAC can be a useful security tool. It can help control what devices connect to your network, authenticate them, and sometimes check whether they meet a company’s security requirements.
Sounds pretty good, doesn’t it?
Well, there’s a catch.
During a penetration test I performed, I came across a company that had installed NAC to protect its network. Employees had to authenticate their computers before connecting. But the company hadn’t thought through everything else plugged into the network, and that turned out to be a pretty big problem.
For this article, I’ll call the company Widget Makers. The company name, network addresses, and diagram are fictionalized, but the penetration test and the weakness I demonstrated were real.
The point isn’t that NAC is useless. It’s that you can spend a fortune on security equipment, but if you don’t understand how everything on your network fits together, you can still leave the front door wide open.
The Widget Makers Network
Widget Makers had a corporate network, CorpNET, and a production network, ProdNET, containing classified information. The networks were separate on paper, but traffic between them was not properly restricted. That meant a problem on the corporate side could become a problem on the production side.
The company also used SIP phones and network printers. The phones were connected to the corporate network rather than being isolated on a dedicated voice network. Employee workstations had to pass the NAC checks, but certain other devices were allowed on through exceptions.
And that’s where things started getting interesting.
What NAC Does — and What It Doesn’t
Network Access Control is supposed to help decide which devices can join a network and what access they should receive. Depending on the product and how it’s configured, that might involve 802.1X, RADIUS, certificates, device posture checks, or an installed agent.
Not every device can use the same authentication method. Printers, phones, cameras, and other equipment sometimes need special handling. Some can use 802.1X just fine; others end up using MAC Authentication Bypass, or MAB, or another exception.
A MAC address is useful for identifying a network interface, but by itself it’s not strong proof that the device is what it claims to be. If you treat a MAC address like a password, you’re asking for trouble.
That’s not a failure of every NAC product. It’s a failure of the security policy and the way exceptions are handled.
How I Found the Opportunity
While walking through the office during the authorized test, I noticed a cubicle with a calendar hanging on the wall. According to the calendar, the woman who worked there was on vacation for the entire week.
Well, that was convenient!
On her desk was a SIP phone connected to CorpNET. I knew from the network configuration I was testing that the phone was allowed on through an exception rather than the normal workstation authentication process.
So I had an unattended location, a trusted device, and an exception in the access-control policy. Put those together and you have something worth testing.
How I Got Around the NAC
I disconnected the SIP phone and connected a WiFi Pineapple in its place. During the test, I configured the Pineapple to present the phone’s MAC address, then placed the device out of sight under the desk.
The network accepted the device under the phone’s existing exception. I hadn’t compromised the NAC appliance or obtained an employee’s credentials. I had taken advantage of the way the network was configured to trust a particular kind of endpoint.
And I wasn’t finished.
From the Parking Lot to ProdNET
Once the Pineapple was in place, I went out to the company parking lot and connected to it wirelessly. I was now on CorpNET without running the NAC agent or authenticating as an employee.
Remember ProdNET, the production network containing classified information? Because the company hadn’t properly isolated it from CorpNET, I was able to reach ProdNET from the parking lot.
I ran Nmap against the production network and captured a screenshot of the results for my penetration test report. That gave me evidence of network reachability and the impact of the NAC bypass.
Important: Accessing classified data was NOT in scope. I did not access, retrieve, or examine any of that information. I demonstrated the network exposure and stopped within the authorized limits of the test. The original screenshot isn’t reproduced here.
Think about that for a minute. I was outside the building, wirelessly connected through a device hidden under a desk, and able to scan a production network that should not have been reachable from an unauthorized endpoint.
The NAC was doing what it had been told to do. Unfortunately, the company had told it to trust something that was easy to impersonate.
Why It Worked
Access-control exceptions
The phone was treated differently from employee workstations. That exception became the opening. An approved MAC address was not sufficient evidence that the approved phone was still connected.
Network design
CorpNET and ProdNET had inadequate separation. Once I reached CorpNET, the lack of effective access restrictions allowed the test to extend to ProdNET.
Physical opportunity
An unattended cubicle gave me a place to connect test equipment without immediately disrupting an employee who was at work.
Wireless exposure
The device created a wireless path back into the wired corporate network. That extended the exposure beyond the physical office space.
None of these weaknesses had to exist together. But when they did, the impact was much greater than any one of them on its own.
How They Could Have Prevented It
- Segment the networks properly. Production systems should have their own security boundaries, with explicit firewall and access-control rules. Separate VLANs alone don’t help much if everything is allowed to talk to everything else.
- Use stronger device authentication where supported. 802.1X and certificate-based authentication can provide stronger identity checks than trusting a MAC address alone.
- Restrict exceptions. Devices that require MAC-based access should receive only the access they actually need. A phone shouldn’t have broad access to production systems.
- Watch for unusual devices and changes. Switch-port telemetry, NAC logs, device profiling, and monitoring can help identify unexpected endpoint changes or wireless bridges.
- Include physical security in the design. Unused ports, unattended workspaces, and exposed network jacks matter. Network security doesn’t stop at the switch configuration.
- Test the whole path. Don’t just verify that the NAC agent blocks an unknown laptop. Test exceptions, the privileges those exceptions grant, and whether sensitive network segments remain protected after a foothold on a lower-trust segment.
And remember, modern NAC systems vary quite a bit. Some can authenticate phones, enforce dynamic VLANs or downloadable ACLs, and profile devices. The lesson here isn’t that all NAC products are broken; it’s that security controls are only as good as their deployment and the architecture around them.
The Lesson
I’ve said it before: you can buy all the expensive security appliances you want, but they won’t make up for poor network design.
In this test, the NAC wasn’t the only issue. The exception for the phone got me onto CorpNET, and the lack of segmentation let me reach ProdNET. Those were separate problems, and together they turned a local access-control weakness into a much bigger finding.
NAC can be a useful layer of security. Just don’t confuse another layer with a complete security strategy.