As many as 366 Okta customers might have had their data ‘acted upon’ following the LapsusUS$ cyberattack against the identity security giant’s customer support subcontractor.
“A small percentage of customers – approximately 2.5 percent – have potentially been impacted and whose data may have been viewed or acted upon,” Okta Chief Security Officer David Bradbury wrote in an update posted at 9:31 p.m. ET Tuesday.
The San Francisco-based company didn’t provide details around how these customers were impacted but said affected customers will receive a report that shows the actions performed on their Okta tenant during the period in question. Okta said impacted customers might want to complete their own analysis, noting the report the company is providing should allow clients to assess the situation for themselves.
“Our customers are our pride, purpose, and #1 priority,” Bradbury wrote in the update. “We take our responsibility to protect and secure customers’ information very seriously. We deeply apologize for the inconvenience and uncertainty this has caused.”
The cyberattack came to light early Tuesday when data extortion gang LapsusUS$ posted screenshots to its Telegram channel of what it alleged was data from Okta customers. LapsusUS$ claimed it acquired “superuser/admin” access to Okta.com and used that to access Okta’s customer data. Okta’s stock fell US$2.98 (1.76 percent) to US$166.43 per share in trading Tuesday, and another US$0.04 in after-hours trading.
The screenshots LapsusUS$ published online were taken from a computer used by a Sitel employee, which Okta contracts with for customer support work. The hacker obtained remote access to the Sitel support engineer’s computer using remote desktop protocol (RDP) and was able to control the machine. The machine was logged into Okta at the time of compromise, though there wasn’t account takeover.
The majority of support engineering tasks are performed using an internally built application called SuperUser, which allows for the performing of basic management functions on Okta customer tenants. The threat actor had access to the Sitel environment from Jan. 16, 2022, until Jan. 21, 2022, when the user’s Okta sessions were terminated due to an attempt to add a new MFA factor from a new location.
Over the past 24 hours, Okta said it has analyzed more than 125,000 log entries to determine what actions were performed by Sitel employees during the five-day period in question. The company determined that 366 Okta customers – or about 2.5 percent of the company’s overall customer base – had their Okta tenant accessed by Sitel during the time period in question, according to Bradbury.
Okta said its third-party customer support engineers use a number of tools in their work including Okta’s instances of Jira, Slack, Splunk, and RingCentral, and support tickets through Salesforce. Support engineers are able to facilitate the resetting of passwords and multi-factor authentication factors for users, but are unable to obtain the passwords themselves, according to Bradbury.
Sitel in January brought in a forensic firm, which it did not identify, to perform an investigation, Okta said. The firm’s investigation and analysis lasted until Feb. 28, and the firm provided a report to Sitel on March 10. Okta received a summary report about the incident from Sitel on March 17, which didn’t contain the screenshots captured by LapsusUS$. The complete investigation report wasn’t given to Okta until Tuesday.
“I am greatly disappointed by the long period of time that transpired between our notification to Sitel and the issuance of the complete investigation report,” Bradbury wrote in a blog post Tuesday. “Upon reflection, once we received the Sitel summary report we should have moved more swiftly to understand its implications.”
Neither Okta nor Sitel immediately responded to CRN requests for additional comment and Okta failed to disclose the compromise in its annual report issued March 7.
In one screenshot shared on social media, a Cloudflare employee’s email address was visible, along with a popup indicating the hacker was posing as an Okta employee and could have initiated a password reset. In response, Cloudflare said it decided to force a password reset for the 144 Cloudflare employees who’ve reset their password or modified their MFA between Dec. 1, 2021, and Tuesday.
Cloudflare said it uses Okta internally as its identity provider and integrates Okta with Cloudflare Access to guarantee that the company’s users can safely access internal resources. Okta is only used for managing the accounts of Cloudflare employees and is not used for customer authentication on Cloudflare’s systems, nor does Cloudflare store any customer data in Okta, according to the company.
“We have multiple layers of security beyond Okta and would never consider them to be a standalone option,” Cloudflare co-founder and CEO Matthew Prince tweeted early Tuesday. “Okta is one layer of security. Given that they may have an issue we’re evaluating alternatives for that layer.”
