On March 22, 2022, information about the compromise of the identity of the Okta platform by the hacker group Lapsus$ appeared on the Internet. It is also behind the recent attacks on Samsung and Nvidia. The Lapsus$ group on Twitter posted screenshots from the Okta admin portal of various customers – e.g. from Cloudflare’s tenant. According to the Reuters report and Okta’s subsequent response, however, this appears to be an earlier incident from January of this year, when the computer of one of the external support engineers working for Okta was compromised and misused. Within moments, the less informed media picked up on this and sensationalism began to swell, see for example the article “Avalanche effect is coming, data of tens of millions of people is at risk. Hackers attacked identity managers” on Novinky.cz. On the same day, Okta informed us of the incident through a partner channel, saying that it was indeed a 2-month-old matter and there was no reason to worry or take precautionary action.
As a partner, supplier and customer of Okta, we have prepared this short article to summarize the nature of the incident, the impact and possible migration. For a detailed description of the incident and background from an engineer on Okta’s security team, see Okta’s Investigation of the January 2022 Compromise
Mechanism and effects of the attack
Okta uses subcontractors for some activities, such as customer support, whose technical staff are then given the ability to log in with their Okta account to the customer tenants they are currently supporting. These logins are inherently limited, for example they cannot create or delete users, download data, etc.
In January 2022, one such Sitel subcontractor took control of an administrator’s device using the classic and primitive method of hacking RDP access (remote desktop) to his station. After taking control of the station, the attackers also got the opportunity to try to use his Okta login. Within days, Okta’s security team noticed an attempt to add another factor to the compromised account (namely the password), and subsequently Okta blocked the account and informed Sitel that they had suspicious activity on the network. The subsequent investigation into Sitel was only concluded in March, meanwhile Okta found that during the 5 days the device was compromised, the account in question had restricted access to 375 tenants out of a total of about 15,000 customers, or 2.5%. Subsequent analysis of the logs in these tenants ruled out suspicious activity, presumably due to the inability to log in via the second factor, yet these customers were contacted and provided with reports on their activity during the period in question.
The Lapsus$ group, which was behind the breach, apparently tried to boost its media position at least in terms of marketing, given the failure of its own hack, and published screenshots from the controlled station with a two-month delay, which do not contain any evidence of malicious behavior.
Conclusion
There is no reason to panic or even lose confidence for Okta’s solution; on the contrary, Okta’s security standards led to the incident being detected by another organization and its impact minimized. However, communication about the incident did not take place as it should have, Okta underestimated what today’s media can make of a relatively ordinary scenario.
If you are an Okta customer and you have not been contacted and informed by them, you can rest easy – your tenant has not been affected by this incident at all, and this also applies to all Okta customers of System4.
Recommendations for clients
If you are still slightly paranoid, you can follow these recommendations of ours , which are generally valid:
- Search the log for password resets and MFAs since the beginning of the year and consider changing passwords for these users
- Disable security question settings and the ability to use them to reset passwords/MFA
- Limit MFA / password reset channels, shorten validity of reset codes
- Enable mail notifications for users when logging in from new devices / password reset / MFA
- Force MFA for logging into all applications and set only secure factors (disable mail, SMS, voice, etc.)
- Reduce session lifetime in authentication policies
- Set up automatic blocking of inactive user accounts
- Limit the number of administrators in Okta
For the future, we recommend considering Passwordless authentication using Adaptive MFA.
