Media hype
On March 22, 2022, information about a security incident on the Okta platform identity appeared on the Internet, apparently based on this Reuters report, which, however, immediately states that it is an older incident without serious consequences. In a short time, less informed media caught on and sensations began to inflate, see for example this article on the seznam.cz. On the same day, Okta informed us via the partner channel that the incident was really a 2-month-old thing and there was no reason for concern or preventive action.
As a partner, supplier, and customer of the Okta service, I have prepared this short article, which summarizes the nature of the incident, the impacts and possible digitization. A detailed description of the incident and the context from the Okta security team engineer can be found here 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 then gets the opportunity 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 administrator’s device of such subcontractor Sitel was taken over by attackers, using the absolutely classic and primitive method of hacking RDP access (remote desktops). After taking control of the device, the attackers also gained the opportunity to try to use his Okta login. In few days Okta security team noticed an attempt to add another factor to the compromised account (namely the password), and subsequently the account was blocked by Okta and Sitel was informed that they had suspicious activity in the network. A follow-up investigation at SItel did not close until mid-March, when report was provided back to Okta and public. Meanwhile Okta found that during the 5 days that the facility was compromised, the account had limited 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, probably due to the impossibility of logging in through the second factor, yet these customers were contacted and received reports on activities during the incriminated period.
The Lapsus $ group, which was behind the intrusion, apparently tried to boost its media position due to the failure of its own hack, and published screenshots of the controlled station, which did not contain any evidence of harmful conduct, with a two-month delay.
Conclusion
There is no reason to panic or even lose confidence in Okta’s solution; on the contrary, Okta’s security standards have led to the detection of an incident at another organization and the minimization of its effects. However, communication about the incident did not go as well as it should have, Okta underestimated what today’s media could do out of this relatively common scenario.
If you are an Okta customer and you have not already been contacted and informed by them, you can be completely at ease – your tenant has not been affected by this incident and this also applies to all Okta System4u customers.
Recommendations for clients
If you are still slightly paranoid, you can follow our recommendations, which are generally valid:
- Search the password and MFA password resets since the beginning of the year and consider changing passwords for these users
- Disable security questions and use them to reset your password / MFA
- Restrict MFA / password reset channels, shorten the validity of reset codes
- Enable mail notification for users when logging in from new devices / password reset / MFA
- Force MFA to log in to all applications and set only secure factors (disable mail, SMS, voice, etc.)
- Reduce session lifetime in authentication policies
- Set up automation to block inactive accounts
- Limit the number of administrators in Octa
and in the future consider implementing Passwordless authentication using Adaptive MFA