Okta's Phishing and MFA Social Engineering Attack

Many years ago, I attended  a security conference and observed a demonstration on how ‘easy’ it is to get into a car that has been locked with a remote key fob. “If someone really wants to get into your car, they will. Let me show you how!” he said, like an excited child (I can say that because I was following his every word and movement like an excited child, as well.)

Like something out of a James Bond film, he opened up a briefcase concealing a laptop and some radio equipment, walked ‘inconspicuously’ into the shadows (behind his realistic car thief presentation booth) and aimed his antenna at the unassuming person locking up their car with a key fob.

His laptop screen displayed a fancy graph that consisted of algorithms and radio frequencies, undeniably outside of my grasp, as he explained how he had collected the signals needed to perform the crime. After cranking on the keyboard a bit, the car alarm on his target car beeped once, signaling the locks had been remotely opened.

From that point on, I figured it would be best for me to only buy used, inexpensive cars, as I had seen first hand that car security was merely a figment of my imagination. Although that was a pretty fancy demonstration of breaking into a car (a car, not all cars) the fact of the matter is that there are easier ways to break in. I experienced that truth first hand when I left my doors unlocked after returning home late one night, only to find out in the morning that a thief had simply opened the unlocked door to get the goodies I had left inside.

We can draw parallels of the ‘easy way’ and the ‘hard way’ when thinking of how people are hacking into organizations’ identity systems. Some hackers use matrix-style, 3D three-finger pinch, shrink, expand and move gestures on Angertron 2000 crime platforms to break into your organization (these methods are often accompanied by holographic light and dubstep or techno background music). Other cybercriminals, lacking the theatrics and music, simply send someone a text message and wait for them to voluntarily (unknowingly) send their credentials, along with MFA tokens.

Okta has been alerting users to a recently occurring scenario, similar to the above. No fancy Angertron 2000s, just a convincing phishing text. Once the attackers gather the credentials they need, they pick up the phone and ask the organization’s helpdesk for MFA factors to be reset. When the help desk obliges them (either because of not following procedures or because the procedures were obviously flawed) the criminals are in.

There wasn’t a lot of tech involved; just a website to mimic the users’ Okta logins and carefully mastered calls to the helpdesk. They were able to simply ‘open the door.’

These criminals are targeting accounts that possess standing administer-level credentials. In the wrong hands, they can be used to remove or reset MFA, as well as elevate privileges across other accounts. Effectively acting with admin credentials, these attackers are also able to move laterally across the organization by modifying IDP settings, allowing impersonation attacks into additional systems.

Social engineering-based attacks against IDPs aren’t new. There are too many to discuss here, but a recent, well publicized one was 0ktapus, where at least 169 domains were involved. With IDP-focused attacks now the new normal, you need to mitigate your risk of falling victim. Here are some best practices on how to do that:

Identify and Restrict the use of highly privileged accounts

When your users are in a least-privileged access (LPA) state after requesting just-in-time (JIT) access, you need to ensure those people should indeed have that access (Think of this as making sure all your drivers are licensed to drive before giving them the keys, as well as verifying how many sets of keys you have.)  Trustle helps you audit your users and permissions, and ensure LPA is in fact LPA by comparing permissions across teams, departments and titles, verifying that all assigned permissions are actually being used.

Keep users at zero-standing privilege (ZSP) until LPA JIT access is required 

By keeping your users’ accounts at ZSP until JIT, LPA is needed, these credentials will be a lot less useful to the attacker—even if their credentials are hacked.  (Think of this as keeping your car locked, and keeping all the valuables out of it, until you actually go for a drive.) Trustle provides timebound access and workflows to keep your users at ZSP until JIT, LPA is needed.

Gain Unparalleled Visibility into Cross-Tenant and Phishing Attacks with Trustle’s new MFA, IP, and Device Detections Pack (Currently in Closed Beta)

Implementing ZSP until JIT, LPA is required is the first step, but when your users need that LPA access, what signals are you operating with to help you efficiently determine if the request is actually coming from who you think it is?

To help mitigate phishing and cross-tenant impersonation attacks, it’s critical for all stakeholders to know the following before granting or provisioning a user access to a resource:

• When was MFA for this requesting principal last reset or downgraded?
• When were permissions last changed, what was the reason for the permission changes, and who made them?
• Has this user ever requested this access before?
• Is the user requesting the access during their specific working hours?
• Has the IP or device being used to make the request been used before?
• Is the user coming in from a well known anonymizing proxy?

It used to be impossible to coordinate this information during JIT access request workflows, as the requesting principal’s IT team, InfoSec team and manager are all different people.   But not any longer!  Trustle’s new MFA, IP and Device Detections Pack provides this data, in realtime, to all approving stakeholders, helping verify the legitimacy of JIT access requests.  Click here for more info on getting on the beta list, and seeing first hand how having this data can dramatically mitigate phishing attack risks within your organization.

Conclusion

In this post, I discussed what many IDP companies are identifying as a social engineering trend of phishing for credentials to gain elevated access, within the IDP itself and beyond, for lateral movement.  

I then discussed some best practices to help mitigate the risk of compromised access elevation, as well as signals you should be detecting when granting access to ensure your requesting principal is who they say they are.

I also made some terrible car analogies, but it felt right at the time.

If you’re interested in implementing some of the Trustle-based controls discussed in this article, including our new beta features specific to MFA, IP and Device-related signals, click here for more info.