A deepfaked voice with insider knowledge! This is the sort of spearphishing that is an IT team’s worst nightmare.
Regular phishing attacks are already devastating. When I worked at Google, internal red teams were forbidden from using phishing tactics because they were so effective that we didn’t learn anything new about our security.
The additional OTP token shared over the call was critical, because it allowed the attacker to add their own personal device to the employee’s Okta account, which allowed them to produce their own Okta MFA from that point forward. This enabled them to have an active GSuite session on that device.
So, it seems that Okta and GSuite were linked up here, perhaps by policy, so that having the Okta MFA token gave the attacker this user’s GSuite, which then gave them all of the OTPs along with everything else in Google Authenticator. The corporate GSuite account, in other words, had all of the corporate passwords in it, so all the attacker needed to get everything was to get in between one user’s Okta and their GSuite.
I sense that the neighboring IT professionals are probably torn between wanting to force a particular password service on their users (to prevent them from doing dumb shit like using Lastpass) and not wanting their entire class of users using systems they don’t really understand which might enable this kind of attack. And of course, not wanting them to use post-it notes either.
So, it seems that Okta and GSuite were linked up here, perhaps by policy
Okta is an Identity Provider. The entire point of the product is linking identities across systems. There are very good reasons for doing this.
Without an IdP, employees have to manage their own passwords across many systems. This makes taking an actual inventory during the offboarding process a nightmare. Active identities may be left lingering for years after someone leaves.
An IdP also gives you the ability to enforce policies like using MFA. If the employee manages their own identity, they can choose not to.
The real security hole in this scenario, IMO, is Google Authenticator. Since TOTP codes are simply a shared secret value, you’re essentially passing a plaintext password around. Once a TOTP secret is established, it should never be shared to any other system.
A deepfaked voice with insider knowledge! This is the sort of spearphishing that is an IT team’s worst nightmare.
Regular phishing attacks are already devastating. When I worked at Google, internal red teams were forbidden from using phishing tactics because they were so effective that we didn’t learn anything new about our security.
fido2/webauthn/passkeys are unphishable, totp is not
hope the employee is ok. to err is human.
This sentence is the one that raises my concerns:
So, it seems that Okta and GSuite were linked up here, perhaps by policy, so that having the Okta MFA token gave the attacker this user’s GSuite, which then gave them all of the OTPs along with everything else in Google Authenticator. The corporate GSuite account, in other words, had all of the corporate passwords in it, so all the attacker needed to get everything was to get in between one user’s Okta and their GSuite.
I sense that the neighboring IT professionals are probably torn between wanting to force a particular password service on their users (to prevent them from doing dumb shit like using Lastpass) and not wanting their entire class of users using systems they don’t really understand which might enable this kind of attack. And of course, not wanting them to use post-it notes either.
Okta is an Identity Provider. The entire point of the product is linking identities across systems. There are very good reasons for doing this.
Without an IdP, employees have to manage their own passwords across many systems. This makes taking an actual inventory during the offboarding process a nightmare. Active identities may be left lingering for years after someone leaves.
An IdP also gives you the ability to enforce policies like using MFA. If the employee manages their own identity, they can choose not to.
The real security hole in this scenario, IMO, is Google Authenticator. Since TOTP codes are simply a shared secret value, you’re essentially passing a plaintext password around. Once a TOTP secret is established, it should never be shared to any other system.