Okta Says It 'Should Have Moved More Swiftly' Over BreachLapsus$ Gained Access to a Sitel Support Engineer's Computer Via Remote Hosting
Identity management company Okta says that it should have notified customers of a breach earlier involving Lapsus$, saying that the hacking group compromised a laptop belonging to Sitel, a third-party customer support firm, via remote desktop protocol, enabling it to infiltrate Okta's network.
"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," David Bradbury, chief security officer for Okta, says in a statement issued Wednesday following a breach at the organization by Lapsus$. Bradbury said. "Upon reflection, once we received the Sitel summary report, we should have moved more swiftly to understand its implications."
Okta has said that a third-party customer support engineer's laptop was infiltrated by malicious hacking group Lapsus$ via remote access in an attempt to infiltrate the identity management firm's network.
Bradbury provided a timeline of events for the incident on a virtual call on Wednesday, and in his statement he describes the incident as "embarrassing," comparing it to leaving a laptop unattended in a coffee shop.
He says that the engineer whose machine was compromised worked for the third-party firm Sitel. Contract workers at Sykes, which is run by Sitel, provide customer support to Okta users.
According to Bradbury, 366 enterprise accounts - or 2.5% of Okta's client base - may have been affected by the breach.
Members of the security community have expressed alarm at Okta's response to the incident, which occurred in January and was not disclosed until earlier this week. Lapsus$, in a Telegram post, shared screenshots of its alleged access to Okta's network, sparking concerns over the firm's incident response lag (see: Okta, Microsoft Confirm Breaches Connected to Lapsus$ Hack)
Since Lapsus$ released the screenshots of the breach, Okta has released several statements within 24 hours - some of them contradictory.
In the latest statement, Bradbury details the timeline of events:
- Jan. 20: Okta security team is alerted that a new "factor" was added to a Sitel customer support engineer’s Okta account. "This factor was a password. Although that individual attempt was unsuccessful, out of an abundance of caution, we reset the account and notified Sitel, who engaged a leading forensic firm to perform an investigation," Bradbury says.
- Jan. 21: The Okta service desk terminated the user's Okta sessions and suspended the account to determine the root cause of suspicious activity. The desk shared indicators of compromise with Sitel.
- March 10: An undisclosed forensic firm retained by Sitel released its investigation report.
- March 17: Okta received a summary report about the incident from Sitel.
- March 22: Lapsus$ released screenshots of alleged access to Okta's network on Telegram. Okta received the Sitel investigation report and determined that the Lapsus$ screenshots were related to the January incident.
Bradbury's statement says that the attacker did not compromise Okta services via account takeover. They only accessed "a machine that was logged into Okta… [and] were able to obtain screenshots and control the machine through the RDP session," he says.
He adds that the support engineer did not have "godlike" access and their access was "limited to basic duties in handling inbound support queries."
"Support engineers use a number of customer support tools to get their job done, including Okta’s instances of Jira, Slack, Splunk, RingCentral and support tickets through Salesforce. The majority of support engineering tasks are performed using an internally built application called SuperUser, or SU for short, which is used to perform basic management functions of Okta customer tenants," he says.
Referring to the use of zero trust architecture, Bradbury says that the Okta application was "built with least privilege in mind to ensure that support engineers are granted only the specific access they require to perform their roles. They are unable to create or delete users. They cannot download customer databases. They cannot access our source code repositories."
It is not known if other customers of Sykes, which includes Twilio, Cisco, DocuSign, Apple, PayPal, Splunk and Dell, have been affected. These companies did not respond to Information Security Media Group's requests for comment.
Gap in Timeline
Bradbury says that the forensic firm's report showed that there was a five-day window, between Jan.16 and Jan. 21, when Lapsus$ had access to the Sitel environment.
Responding to concerns over this statement from the cybersecurity community, Okta, in its Wednesday blog, says that it has "examined all of the access performed by all Sitel employees to the SuperUser application for the five-day period in question."
"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," Bradbury adds.
Bradbury, in the Okta blog post, maintains that the company's "service has not been breached and there are no corrective actions that need to be taken by our customers."
He says that customers who "may want to complete their own analysis" will receive a report that shows the actions performed on their Okta tenant by Sitel. "We think this is the best way to let customers assess the situation for themselves," he says.
But Okta customer Amit Yoran, CEO of Tenable and former president of computer and network security company RSA, says that Okta has not contacted his company to confirm whether it is at risk or to offer mitigation guidance.
"As a customer, all we can say is that Okta has not contacted us and to the best of our knowledge, we are not affected by the breach. Out of an abundance of caution, we are taking what we believe to be logical actions to minimize exposure," he says.
"The first question I asked myself after learning of the Okta breach was, 'Are we exposed?' That’s an incredibly simple, but crucial question - one that Okta customers should have had the chance to ask themselves two months ago when the company first discovered the compromise," Yoran says.
He adds that Okta has not published indicators of compromise or best practices to mitigate any potential increase in risk.
Brett Callow, threat analyst at cybersecurity firm Emsisoft, says that it is in the breached company's best interest to be proactive and speedy with disclosures communications. "This is not only so that clients and business partners can take whatever action they consider necessary to mitigate their risks, but also to avoid what may be a relatively minor incident escalating into a PR disaster," he tells ISMG.
Adding to Callow's statement, Jake Williams, a former member of the National Security Agency's elite hacking team, says that there's no reason why the forensic investigation at Sitel should have taken as long as it did.
"It's not clear at all why Okta needed to wait for a final forensics report before beginning its own investigation to protect its customers. Okta didn't know the full scope of the intrusion, but they certainly had some information to work with," Williams, now CTO of cybersecurity firm BreachQuest, tells ISMG.
Okta did not respond to ISMG's request for additional comments.
Sitel, in a statement to ISMG, says that it took "swift action to contain the incident and to protect any potentially impacted clients, following a security breach in January 2022."
It says that the company is "confident there is no longer a security risk," adding that it continues to investigate potential security risks to both its infrastructure and global clients.
The Australian CERT, in a bulletin, says that it will share indicators of compromise of previous Lapsus$ attacks with its customers and "continue to provide incident response and advice."
A security analyst who calls himself elgervinicius has shared some indicators of compromise here.
Security solution provider Kaspersky has also shared insights on the consequences of the incident, as well as mitigation-related security advice, with Okta customers.
The Okta breach, Kaspersky experts say, can "explain a number of the rather high-profile data leaks from large companies, for which hackers from LAPSUS$ have already claimed responsibility."
In light of the Okta incident, the cybersecurity company says organizations must monitor network activity, especially "related to authentication in internal systems." It also says they must:
- Restrict access to remote management tools from external IP addresses.
- Ensure that remote control interfaces can only be accessed from a limited number of endpoints.
- Follow the principle of offering staff limited privileges and granting high-privileged accounts only to those who need this to fulfil their job.
- Use ICS network traffic monitoring, analysis and detection solutions for better protection from attacks potentially threatening technological process and main enterprise assets.
Security company Digital Shadows says Okta customers must review Okta logs for suspicious activity and "pay particular attention" to the following events:
- eventType eq "user.mfa.factor.deactivate"
- eventType eq "user.mfa.factor.reset_all"
- eventType eq "user.account.update_password"
- eventType eq "user.lifecycle.activate"
- eventType eq "system.api_token.create"
The company also advises Okta enterprise clients to review tools that Lapsus$ uses routinely, such as DSync and Mimikatz. "The group have been reported using several other methods of "living off the land," so legitimate tools should also be considered," the company says.
"Lapsus$ is also known to exploit vulnerabilities in Confluence, JIRA and GitLab. Ensure any vulnerabilities affecting these services are patched," it adds.
ISMG Staff Writer Devon Warren-Kachelein contributed to this story.