According to Okta Security on 11 December 2024, Okta identified an increase in phishing and social-engineering attempts claiming to be from Okta Support. Attackers sought customer passwords and MFA tokens from workforce users at Okta customer organizations. Okta states legitimate Support will not ask for a password or an MFA token, and incoming caller ID alone should not validate the caller as authentic.
If you want the prevention angle, read the related article on mfa2point0.com.
FAQ
What did Okta's December 2024 Support-impersonation advisory say?
According to Okta Security on 11 December 2024, Okta identified an increase in phishing and social-engineering attempts claiming to be from Okta Support. The attackers sought customer passwords and MFA tokens. Okta's advisory states that Okta Support will not ask for a password or for an MFA token, and that incoming caller ID alone should not validate the caller as authentic because calls can be spoofed.
How does fake Okta Support defeat MFA that is already turned on?
Fake Okta Support social engineering defeats legacy MFA when a workforce user hands over a password plus a transferable MFA token under live coaching. OTP codes, SMS codes, email codes, and push approvals can be read out, forwarded, or approved once the victim believes the contact is real Support. That is credential-phase failure at the moment of transfer, not magic after a finished login. Public reporting on this Okta advisory does not describe AiTM reverse-proxy kits, device-code OAuth flows, TAP issuance, or post-login session cookie theft as the method used.
Did Okta name customers, attackers, or a victim count?
No. Public reporting does not establish named customer victims, named threat actors, a quantified victim or record count, or ransom figures for the Okta Support impersonation campaign. The 11 December 2024 disclosure is a vendor advisory about increased attempts against Okta customers, not a single-company breach filing with impact numbers.
How should teams treat a call or email that claims to be Okta Support?
Teams should not treat caller ID, urgency, or a support-sounding script as proof of authenticity. According to Okta, when a support case is open, Support may contact by phone or email and uses an initial validation process for authorized representatives. Rapid security alerts go only to the organization's security and privacy and primary IT contacts on file. Verified email channels cited include support@okta.com, support@auth0.com, noreply@securityalerts.okta.com, and noreply@okta.com. Anyone asking for a password or an MFA token is not legitimate Okta Support.
Is this the same failure class as helpdesk password-reset social engineering?
Yes. Coaching a user to hand a password and a live MFA token to fake Okta Support sits in the same class as talking IT into a recovery secret or password reset: both are live social engineering of a transferable factor. The M&S helpdesk password-reset case is another workforce example of that pressure path. A fix exists that removes phishable shared secrets and out-of-band codes so coached transfer does not yield a usable login. The companion post covers prevention; this advisory is the what-happened record.
