If Only They Had a NAC…Understanding the Cisco Hack

Cisco recently confirmed they were the victim of a data breach in which hackers were able to steal 2.8 GB of data. Although these breaches are nothing new (SolarWinds, Credit Suisse, Twitter, the list goes on…) the Cisco breach is especially concerning because many organizations rely on Cisco products to keep their networks safe.   

The Cisco Hack: What Happened?

The threat actors behind the Cisco hack were able to successfully compromise an employee’s personal Google account.  Since the employee had enabled password syncing via Chrome and had saved their Cisco credentials in their work browser, once the account was compromised the hackers had the first bit of information they needed to break in.   

MFA Fatigue & Vishing

Of course, Cisco has MFA (multi-factor authentication) set up for VPN access, so the hackers then used a combination of MFA Fatigue and Vishing (Voice Phishing) attacks to get the employee to accept a push notification. MFA Fatigue is when they spam your device with Push requests to allow access; if you’ve ever accidentally clicked “OK” when you meant to click “Cancel” you know how easy it can be to get it wrong and it only takes once. And if you didn’t know beforehand this was a method hackers use to get break into a VPN….you might just assume it was a glitch, press OK and move on. 

 Vishing is when someone calls you and pretends to be from a legitimate business entity to get you to give up personal and/or financial details. Your first thought is likely to be “I would never fall for that” but these bad actors have plenty of information stored on you to convince you that they’re really calling from where they say they are. Such tactics often include number spoofing to impersonate your bank or corporate office, to confirm details like your credit card number and the last four digits of your SSN.  Everyone has a story of a “near miss” when they almost clicked on a suspicious link or answered some questions they shouldn’t – it only takes one moment of being too trusting.     

And Then…

From there the hackers went on a whirlwind tour of expanding the systems they could access until they reached a domain controller, downloading all the user data, enrolling other devices for VPN access, creating a new user just called “Z” and adding them to the local administrators group, and installing other hacking and access tools like TeamViewer, LogMeIn, Cobalt Strike, and more.  

There is an excellent, detailed write-up here for those interested in a deep dive.   

Could a NAC Have Stopped the Cisco Hack?

Is there a tool that could have prevented the Cisco hack from happening?  If you had a robust NAC solution like Portnox NAC-as-a-Service, would you be safe from this kind of attack?  The answer is absolutely, without a doubt…maybe. 

ZTNA (Zero-Trust Network Access) is a term that gets thrown around a lot, but this is a perfect example of why it’s so important. It boils down to this: your network should never trust that you are who you say you are. Many people think of VPNs as totally safe, and you’ve probably rolled your eyes a time or two when you had to go through the extra MFA step, but when it comes down to it, you don’t want trust just any device accessing your network, even if the user account is valid (because as we know from the Cisco example, sometimes it simply isn’t.) 

So, the best way to prevent a compromised account from accessing your network is to make sure access is limited to only people AND devices you trust. 

Without a VPN, this is easy – you can use the MAC address of the device to verify it and block anything that is using an unknown MAC even if the user credentials are valid. When you introduce a VPN, though, it becomes a little trickier, because VPNs use a ‘virtual’ network interface with a completely made-up MAC address. 

The best way to accomplish true ZTNA is via user account and certificate validation.  Certificate-based authentication is the use of a digital certificate to identify a device before granting access to a network resource (versus granting access to any device when a user account is valid.)  Certificates are stored on a specific device, signed by a trusted root certificate authority, and are only good for a set amount of time. Your NAC checks for the certificate to be valid and properly signed when you try to log in, thus verifying both the user account and device.  While certificate-based authentication is certainly not new, it is gaining popularity due to closing the gaps left by purely password-based authentication. 

There is also a possibility of using ComputerName as a RADIUS Attribute, but the device needs to support additional RADIUS attributes and not all of them do.  If your network is comprised of hardware from several different vendors, certificates are the way to go when you need your solution to be truly vendor agnostic.   

Users are always the biggest threat to network security, and at the end of the day most of our tools are designed to save us from the people who also need access to internal resources to keep us running.