Okta disclosed that a threat actor used a stolen credential to breach its support case management system and view customer files, but questions around the attack scope and timeline remain.
In a blog post Friday, Okta CSO David Bradbury confirmed that an unknown threat actor viewed recent customer support case HTTP Archive (HAR) files uploaded to the identity and access management vendor’s support case management system. Bradbury emphasized that attackers leveraged a set of stolen credentials to access the support system, but said it’s separate from the production Okta service, which was not compromised. Okta has notified all affected customers.
During the attack, threat actors targeted HAR files, which Okta support uses for troubleshooting assistance, that contained session tokens and could be used to impersonate valid users. In response, Okta revoked embedded session tokens and reevaluated the way HAR files are handled.
“In general, Okta recommends sanitizing all credentials and cookies/session tokens within a HAR file before sharing it,” Bradbury wrote in the blog.
While Bradbury confirmed that stolen credentials were leveraged in the attack, he did not say how or when they were acquired. The attack scope remains unknown as well; Bradbury only revealed that the breach affected “certain Okta customers.” TechTarget Editorial contacted Okta for additional information, but the vendor did not provide further information outside of what was disclosed in the blog.
However, two separate disclosures, also published on Friday, from customers BeyondTrust and Cloudflare shed further light on the Okta breach.
More notably, the disclosures confirmed that Okta did not initially detect the breach. In a blog post Friday, BeyondTrust said it first detected threat activity earlier this month and alerted Okta, though it was met with a slow response. BeyondTrust added that it detected and remediated the attack with no effect on customers.
“The initial incident response indicated a possible compromise at Okta of either someone on their support team or someone in position to access customer support-related data,” BeyondTrust wrote in the blog. “We raised our concerns of a breach to Okta on October 2nd. Having received no acknowledgement from Okta of a possible breach, we persisted with escalations within Okta until October 19th when Okta security leadership notified us that they had indeed experienced a breach and we were one of their affected customers.”
The blog outlined BeyondTrust’s concerns with Okta’s response, but also applauded the vendor for its transparency in reporting the breach. BeyondTrust first engaged in a Zoom meeting with Okta on Oct. 11 and said it requested additional log data related to support case data access. BeyondTrust emphasized that Okta did not convey that a known compromise or ongoing security incident had occurred at that time.
Okta sent the requested logs two days later, but BeyondTrust said they “contained several discrepancies.”
“We requested more detailed logs relating to the discrepancies and reiterated our concerns that there was a high likelihood of compromise within Okta support and that we were likely not the only customer impacted,” the blog said. “No known compromise or ongoing security incident was communicated by Okta.”
BeyondTrust CTO Marc Maiffret told TechTarget Editorial that it took some time to convince Okta it was the source of the attack. He attributed Okta’s slower response time to the Oktane 2023 user conference that took place Oct. 3-5 and acknowledged that when a third party discloses an incident, the response and investigation can take some time.
“We didn’t get the sense at the beginning that they saw it as a plausible thing that it might be them,” Maiffret said. “I wish that from the beginning they would have been more open to that as an idea. I was on the very last call that I had with them before they called to tell us something had happened. I was racking my brain because I started to feel a bit like a crazy person, like maybe we were missing something.”
Maiffret said BeyondTrust requested logs to examine the extent of what occurred on Okta’s support side. “We knew some requests we had made to the files and in the support portal for different systems, and some of those requests we had made were nonexistent in the logs they gave us,” he said. “At that point, it didn’t give me high confidence that the logs as given were representative of everything that happened from a support access perspective.”
BeyondTrust responds to attack
In addition to the disclosure timeline, BeyondTrust also detailed the attack that started on Oct. 2 when a BeyondTrust Okta administer uploaded a HAR file to Okta support to address a troubleshooting issue. BeyondTrust said malicious activity occurred within 30 minutes of the file upload. The activity originated from an “IP address in Malaysia linked to anonymizing proxy/VPN services” that did not align with the user’s location.
Though the attacker was authenticated, BeyondTrust said two policies prevented further access to the Okta console. The first policy denies access by default and only allows access if specific criteria are met. The second policy requires Okta Verify to be installed on a managed device.
From there, the attacker attempted to abuse several APIs, including one to generate a password health report and another to create a fake service account that mimicked existing accounts.
However, BeyondTrust prevented the attack, contacted Okta and initiated an investigation.
“The investigation did not discover any indication of compromise however it did uncover the HAR file that had been generated for the support case. This was notable as these are only created in exceptional circumstances, in this instance for troubleshooting a support case,” the blog said.
Maiffret said that toward the end of the second week following the initial detection, BeyondTrust set up an Okta honeypot environment to attract malicious activity, but Okta ended up confirming the breach before that data was necessary.
Okta faced further criticism from Cloudflare in a third blog post Friday, titled “How Cloudflare Mitigated Yet Another Okta Compromise.” The security vendor said it discovered an attack on its systems on Oct. 18 that traced back to Okta. Attackers hijacked a session token from a support ticket submitted by a Cloudflare employee to Okta and used that token to access Cloudflare’s systems. Cloudflare observed that the threat actors had compromised two separate employee accounts within the Okta platform.
However, Cloudflare said its “rapid response” prevented any customers from being affected. Like BeyondTrust, Cloudflare voiced concerns over Okta’s disclosure process.
“We detected this activity internally more than 24 hours before we were notified of the breach by Okta,” Cloudflare wrote in the blog.
Okta breach history
Friday’s disclosure marked another security incident involving stolen Okta credentials in recent weeks. Last month Okta confirmed that a social engineering attack occurring between July 29 and Aug. 19 compromised four of the company’s customers, including Caesars Entertainment. In the social engineering campaigns, threat actors targeted customers’ IT service personnel with vishing calls, convincing those individuals to reset multifactor authentication (MFA) factors for privileged users. The threat actors then used compromised Okta super administrator accounts to impersonate legitimate users and move laterally within the victims’ networks.
Another social engineering attack that occurred after those dates affected MGM Resorts. The first wave of social engineering attacks were attributed to Scattered Spider and exhibited vast knowledge of the victim environment as well as vishing techniques. The attacks involved ransomware and caused prolonged disruptions, particularly for MGM, which now faces $100 million in losses.
Friday’s disclosure also marked the second breach for Okta in as many years. In March 2022, Okta confirmed that Lapsus$ threat actors compromised the account of a customer support engineer who worked for a third-party provider, and then used that account to steal customer data. The breach initially occurred in January, and Okta disclosed that by March, 2.5% of customers were affected, including Cloudflare.
Regarding the most recent breach, Okta, Cloudflare and BeyondTrust provided several mitigation recommendations. Okta released indicators of compromise to help customers perform their own threat-hunting activity and reminded users to remain vigilant of suspicious activity.
Cloudflare urged Okta to take any reports of compromise “seriously” and to provide “timely, responsible disclosures” to affected customers. As for Okta customers, Cloudflare emphasized the importance of reviewing session expiration policies to limit session hijack attacks and enabling hardware MFA for all accounts.
As for BeyondTrust, the vendor recommended adding policy controls, implementing MFA authentication challenges at every sign-on and requiring strong hardware MFA for all Okta admins.
“Modern identity-based attacks can be complex, and as this attack shows, can originate from environments outside your own,” the blog post warned.
Arielle Waldman is a Boston-based reporter covering enterprise security news.
