![](\"https:\/\/media.wired.com\/photos\/623a477c28f38333befbabcd\/master\/pass\/Nasdaq-Okta-Sec_AP_17097624872676.jpg\"\/)
<\/p>\n<\/p>\n
Credit to Author: Lily Hay Newman| Date: Wed, 23 Mar 2022 00:13:04 +0000<\/strong><\/p>\n Lily Hay Newman<\/a><\/span><\/span><\/p>\n To revist this article, visit My Profile, then View saved stories<\/a>.<\/p>\n To revist this article, visit My Profile, then View saved stories<\/a>.<\/p>\n The digital extortion<\/span> group Lapsus$<\/a> threw the security world into disarray on Monday with claims that it had gained access<\/a> to a \u201csuper user\u201d administrative account for the identity management platform Okta. Since so many organizations use Okta as the gatekeeper to their suite of cloud services, such an attack could have major ramifications for any number of Okta customers. While Okta has released new details\u2014including clarifying what \u201csuper user\u201d means and the potential extent of the breach\u2014questions about the incident, and the company's handling of it, remain unanswered.<\/p>\n Okta said in a short statement early Tuesday morning that in late January it had \u201cdetected an attempt to compromise the account of a third-party customer support engineer working for one of our subprocessors,\u201d but that \u201cthe matter was investigated and contained by the subprocessor.\u201d<\/p>\n In an expanded statement<\/a> on Tuesday afternoon, Okta's chief security officer, David Bradbury, said categorically, \u201cThe Okta service has not been breached.\u201d The details that have emerged, though, including from Bradbury's statement itself, paint a confusing picture, and the conflicting information has made it difficult for Okta customers and others who depend on them to assess their risk and the extent of the damage.<\/p>\n \u201cThere are two big unknowns when it comes to the Okta incident: the specific nature of the incident and how it might impact Okta customers,\u201d says Keith McCammon, chief security officer at the network security and incident-response firm Red Canary. \u201cThis is exactly the type of situation that leads customers to expect more proactive notification of security incidents that impact their product or customers.\u201d<\/p>\n On Tuesday evening, about eight hours after posting Bradbury's statement, Okta updated the notice with some expanded information. Specifically, the company admitted that roughly 2.5 percent of its customers \u201chave potentially been impacted,\u201d adding that their data \u201cmay have been viewed or acted upon.\u201d In a later update, the company clarified that the \u201cmaximum potential impact\u201d of the breach is 366 customers; Okta reported<\/a> having more than 14,000 customers as of February.\u00a0<\/p>\n Bradbury's original statement said that the company only received analysis of the January incident this week from the private forensics firm it hired to assess the situation. The timing coincides with Lapsus$'s decision to release screenshots, via Telegram, that claim to detail its Okta administrative account access from late January.\u00a0<\/p>\n The company's expanded statement opens by saying that it \u201cdetected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider.\u201d But apparently some attempt was successful, because Bradbury goes on to say that the incident report recently revealed \u201ca five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer\u2019s laptop.\u201d<\/p>\n The statement adds that, during those five days, attackers would have had the full access that support engineers are granted, which does not include the ability to create or delete users, download customer databases, or access existing user passwords but does include access to Jira tickets, lists of users, and, crucially, the ability to reset passwords and multifactor authentication (MFA) tokens. The latter is the main mechanism Lapsus$ hackers would likely have abused to take over Okta logins at target organizations and infiltrate.<\/p>\n Okta says that it is contacting customers who may have been impacted. On Tuesday, though, companies including the internet infrastructure firm Cloudflare raised the question<\/a> of why they were hearing about the incident from tweets and criminal screenshots rather than from Okta itself. The identity management company seems to maintain, though, that compromising a third-party affiliate in some way is not a direct breach.<\/p>\n \u201cIn Okta's statement, they said they were not breached and that the attacker's attempts were \u2018unsuccessful,\u2019 yet they openly admit that attackers had access to customer data," says independent security researcher Bill Demirkapi. \u201cIf Okta knew since January that an attacker may have been able to access confidential customer data, why did they never inform any of their customers?\u201d<\/p>\n In practice, breaches of third-party service providers are an established attack path to ultimately compromise a primary target, and Okta itself seems to carefully limit its circle of \u201csub-processors.\u201d A list of these affiliates<\/a> from January 2021 shows 11 regional partners and 10 sub-processors. The latter group are well-known entities like Amazon Web Services and Salesforce. The screenshots point to Sykes Enterprises, which has a team located in Costa Rica, as a possible affiliate that may have had an employee Okta administrative account compromised. Okta later confirmed the subprocessor as business services outsourcing company Sitel Group, which purchased<\/a> Sykes in September 2021. Sitel, Okta said, hired a forensic firm to investigate the breach. Okta said it received a summary report about the incident on March 17 but didn't receive the full report until Tuesday afternoon.<\/p>\n Sykes, meanwhile, said in a statement, first reported by Forbes<\/em><\/a> on Tuesday, that it suffered an intrusion in January.\u00a0<\/p>\n \u201cFollowing a security breach in January 2022 impacting parts of the Sykes network, we took swift action to contain the incident and to protect any potentially impacted clients,\u201d the company said in a statement. \u201cAs a result of the investigation, along with our ongoing assessment of external threats, we are confident there is no longer a security risk.\u201d<\/p>\n The Sykes statement went on to say that the company is \u201cunable to comment on our relationship with any specific brands or the nature of the services we provide for our clients.\u201d<\/p>\n As for the \u201csuper user\u201d account Lapsus$ claimed to have accessed, Okta said in an updated statement that SuperUser is an application \u201cused to perform basic management functions of Okta customer tenants,\u201d and doesn't provide \u201c'god mode-like access' to all its users."<\/p>\n On its Telegram channel, Lapsus$ posted a detailed (and frequently self-congratulatory) rebuttal to Okta\u2019s statement.<\/p>\n \u201cThe potential impact to Okta customers is NOT limited, I'm pretty certain resetting passwords and [multifactor authentication] would result in complete compromise of many clients systems,\u201d the group wrote. \u201cIf you are commited [sic<\/em>] to transparency how about you hire a firm such as Mandiant and PUBLISH their report?"<\/p>\n For many Okta customers struggling to understand their potential exposure from the incident, though, all of this does little to clarify the full scope of the situation.<\/p>\n \u201cIf an Okta support engineer can reset passwords and multifactor authentication factors for users, this could present real risk to Okta customers,\u201d Red Canary's McCammon says. \u201cOkta customers are trying to assess their risk and potential exposure, and the industry at large is looking at this through the lens of preparedness. If or when something like this happens to another identity provider, what should our expectations be regarding proactive notification and how should our response evolve?\u201d<\/p>\n