You can harden your corporate IT environment as much as you want, and you really should, but it still won’t solve the ultimate problem that can upset all those security efforts. You know what I’m talking about. It’s us. The users. Look, we all try to do our best to not get taken in by phishing email, or download a document we shouldn’t, but sometimes all this security stuff gets to be too much.
The recent Cisco hack by the Yanluowang ransomware group provides an excellent example of how we humans end up being the ultimate weak link. Threat actors gained a foothold into the Cisco network after carrying out what’s known as a Multi-Factor Authentication (MFA) fatigue attack, according to Bleeping Computer. This is a fairly new threat, but it’s essentially the cybersecurity equivalent of kids in the back seat repeatedly asking, “are we there yet?”
After logging in with a pilfered username and password, attackers keep on sending MFA requests until the target gives up in frustration and just authorizes the request. The person likely assumes it’s some kind of technical fault that might go away if they click on that authorization button. Or, as was reportedly the case with the Cisco hack, the attackers impersonated “trusted support organizations” to get the employee to authorize the MFA request.
Once the attackers received the MFA authorization they were able to connect to Cisco’s network, get to work on reconnaissance to achieve lateral movement, and that, as they say, is that.
Cisco says it found no evidence of ransomware on its network, but the hackers claim they did extract more than three thousand company files. This hack could’ve been much worse, but what we want to focus on here is not so much the hack itself, but the MFA attack that led to it, and what companies can do to make sure this doesn’t happen to them.
Before we go any further, let’s discuss what this attack looks like. How can an MFA fatigue attack happen in the first place? Instead of tools like a Yubikey or Google Authenticator, many companies use an app from their IDP as an MFA step. This app creates push notifications every time a user logs in to the network asking if it was really them, the user then taps the Yes/No options, and there we have the problem. Get enough of these push notifications in succession (before the threat actors max out your account’s login attempts), and you just might push yes, instead of no.
It’s not a particularly sophisticated attack, but it’s novel and, so far, effective. So what can we do to combat this form of social engineering? It comes down to three things:
The first thing to do is make sure people are aware of the potential threats out there, and that unusual behavior is a big red flag. The minute they experience something odd it should be reported immediately, and in the case of repeated MFA requests they definitely shouldn’t authorize the login attempt.
Also make sure that you don’t have any systems in place where support staff would need to login to a service or app using an employee’s username, password, and MFA authorization. You’ll also have to train employees to know that they should never give out their login details to anyone, no matter how legitimate they seem, and that includes authenticating with MFA.
If your company doesn’t limit how many times a user can login in a short period of time then it’s a good idea to set such a policy. This is crucial so that repeated attempts at login will set off alarm bells and shut down any potential hacks.
For people with access to mission critical company data see if you can upgrade their MFA requirements. Instead of a frictionless Yes/No option, see if your IDP’s smartphone app offers something more substantial. Okta Verify, for example, can add a number challenge to MFA. In this scenario, the device logging in displays a number, and then the user has to select that same number that appears in the push notification on their phone. That way the user would have to see both pieces of information to get it right.
Another alternative, would be to disallow these apps entirely, and instead require a security key, biometric ID, or an app that generates time-based one-time passwords (TOTP). Admittedly, these methods are not as frictionless as a push notification and they come with their own problems, but it’s an option. One thing you definitely want to avoid is SMS-based MFA as it’s well known to be insecure.
Finally, perhaps the most powerful action you can take is to adopt a zero trust strategy. Taking this posture assumes the threat actors are already trying to get into your network, or have harvested user credentials in their possession.
The motto of Zero Trust is “never trust, always verify.” With Zero Trust you set context-based policies that will refuse access to files or apps if certain conditions aren’t met regardless of how legitimate their login credentials are. The context-based conditions can be geographical such as no logins outside of the U.S. or only in specific countries. The restrictions can also be device focused, as well as time-based. The context rules can also be set so that any login conditions must be sustained during the entire user session. If they aren’t then access is revoked.
Zero Trust is a must-have security layer to face today’s threats, and the best part is it all happens in the background without putting any extra burden on the user.
Perimeter 81’s Zero Trust solution can help your company achieve these aims, and we already integrate with the major IDPs to make your transition smoother.
Book your demo today to see the power of Zero Trust in action.
