UPDATE 3/28/2022 18:49 GMT Okta’s latest partner communication regarding the incident states that any customers or partners of customers (with customer consent) whose information was accessed by Sitel during the unauthorized access window will be notified.
UPDATE 3/23/2022 16:48 GMT Okta has issued a follow-up statement clarifying details of the event which had initially been reported as a breach because a threat group shared screenshots of an internal Okta administrative console.
A forensics firm has determined that during a five day period in January, an attacker had access to a third party (Sitel) support engineer’s laptop, which is how the screenshots were taken. Okta qualifies the extent potential customer data breach in their statement:
The potential impact to Okta customers is limited to the access that support engineers have. These engineers are unable to create or delete users, or download customer databases. Support engineers do have access to limited data – for example, Jira tickets and lists of users – that were seen in the screenshots. Support engineers are also able to facilitate the resetting of passwords and multi-factor authentication factors for users, but are unable to obtain those passwords.
…There is no impact to Auth0 customers, and there is no impact to HIPAA and FedRAMP customers.
Okta states that the support engineer’s access was limited in that “they are unable to create or delete users. They cannot download customer databases. They cannot access our source code repositories.”
Over the past 24 hours we have analyzed more than 125,000 log entries to ascertain what actions were performed by Sitel during the relevant period. We have determined that the maximum potential impact is 366 (approximately 2.5% of) customers whose Okta tenant was accessed by Sitel.
Does the investigation change guidance?
Cloudflare has an excellent writeup of their own investigation into the Okta incident. At the end they make a few recommendations for Okta customers. In additions to authentication lockdown practices that should be standard for any organization, they recommend conducting your own investigation:
- Check all password and MFA changes for your Okta instances.
- Pay special attention to support initiated events.
- Make sure all password resets are valid or just assume they are all under suspicion and force a new password reset.
- If you find any suspicious MFA-related events, make sure only valid MFA keys are present in the user’s account configuration.
Okta has been fairly transparent in their findings by qualifying and quantifying potential of the incident. At this time it appears the risk is unchanged for customers from the original advisory.
Original Security Advisory
MARCH 22, 2022 21:45 GMT IAM service provider Okta is investigating a claim by the LAPSUS$ group that they have breached the company’s administrative portal and are targeting Okta customer data.
Okta released a statement that the screenshots are from an unsuccessful January attempt to breach one of their subprocessors, and that their investigation shows no evidence of ongoing malicious activity.
At this time there is no mitigation or action recommended for Okta customers.
Background
Okta is a leading provider of authentication services and IAM solutions worth more than $6 billion and employing approximately 5,000 people with a long list of Fortune 500 customers.
LAPSUS$ is a threat group most recently taking credit for breaches of Nvidia and Microsoft earlier this year. The group claims to have accessed source code for Bing, Bing Maps, and Cortana products.
LAPSUS$ posted screenshots today of what it says is the Okta administrative portal during its unauthorized access, accompanied by a statement disparaging the security measures of a provider of Okta’s stature.
Okta’s investigation and response
Okta quickly released an official statement on the claims, tracing it back to an attempted account compromise of one of their subprocessors in January of this year:
“In late January 2022, Okta detected an attempt to compromise the account of a third party customer support engineer working for one of our subprocessors. The matter was investigated and contained by the subprocessor. We believe the screenshots shared online are connected to this January event. Based on our investigation to date, there is no evidence of ongoing malicious activity beyond the activity detected in January.”
Okta’s CEO Todd McKinnon tweeted a similar statement. Their investigation is ongoing.
“Subprocessors” in this context are organizations authorized by Okta to process customer data and assist in fulfilling applicable services. This includes some pretty large parties such as AWS, Splunk, and Salesforce.
What’s the risk of an Okta breach?
Despite Okta’s statement, there exists the potential that LAPSUS$ did breach some customer data. Until an in-depth investigation is completed, one can only speculate as to the extent of access achieved while taking the screenshots.
One of the posted screenshots indicates that LAPSUS$ could change customer passwords using Okta’s admin panel.[1]
However the access was achieved could determine whether persistent access methods remain either as LAPSUS$ backdoors or as an unidentified vulnerability.
Customer data acquired during a breach by a threat actor could be used in a variety of ways, including as as intel to use in subsequent attacks on that customer. Any persistent mechanisms installed to exfiltrate further data or harvest credentials could be a very serious situation for an IAM player of Okta’s stature.
Is there any action to take at this time?
There is no recommended mitigation action recommended for customers by Okta at the time of this writing. A follow-up advisory will be sent if the situation changes.
Resources
- “Okta investigating claims of customer data breach from Lapsus$ group”
https://www.bleepingcomputer.com/news/security/okta-investigating-claims-of-customer-data-breach-from-lapsus-group/ - “Okta Official Statement on LAPSUS$ Claims”
https://www.okta.com/blog/2022/03/okta-official-statement-on-lapsus-claims/ - “Okta subprocessors”
https://www.okta.com/sites/default/files/SUBPROCESSORS_Public_facing_content_3-16-18_v2.pdf - “Okta’s Investigation of the January 2022 Compromise”
https://www.okta.com/blog/2022/03/oktas-investigation-of-the-january-2022-compromise/ - “Cloudflare’s investigation of the January 2022 Okta compromise”
https://blog.cloudflare.com/cloudflare-investigation-of-the-january-2022-okta-compromise/
