Scope of Okta helpdesk breach widens to impact all users

[ad_1]

Identity and access management (IAM) specialist Okta has warned customers to keep their guard up, after its ongoing investigation into a compromise of the Okta Help Center customer support management system turned up evidence that the threat actor may have compromised much more data than thought – indeed, all customers who have used the system may now be at risk.

The incident saw a threat actor leverage a stolen credential – obtained from one of its own employees who used a corporate device to sign into a compromised personal Google account – to access Okta’s case management system and view HTTP Archive (HAR) files uploaded by customers to allow its agents to troubleshoot their issues.

Such files can also contain data such as cookies and session tokens of value to a cyber criminal.

At the time, a small subset of customers was believed to be affected – and some of these identified themselves via their own disclosures – but new information has now come to light that has enabled Okta to determine that the scope of the breach is far wider than that.

“We have determined that the threat actor ran and downloaded a report that contained the names and email addresses of all Okta customer support system users,” said Okta chief information security officer David Bradbury.

As such, all Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers are impacted by the cyber attack – except for those in its US government FedRamp High and DoD IL4 environments. The Auth0/CIC support case management system was also not impacted.

The report obtained contains fields that include the date of account creation, last login, full name, username, email address, company name, user type, address, date of last password change, job title, job description, phone number, mobile number, time zone and SAML Federation ID.

Blank fields

However, Bradbury said the majority of the fields were blank and the report did not include credentials or sensitive information. For the vast majority – over 99% of customers – the only information actually stolen was names and email addresses.

“While we do not have direct knowledge or evidence that this information is being actively exploited, there is a possibility that the threat actor may use this information to target Okta customers via phishing or social engineering attacks,” said Bradbury, who added that there was very likely an increased risk that will happen.

Okta said it uncovered the true extent of the breach after further review of the actions the threat actor performed found the file size of one report they downloaded was much larger than the file Okta had generated during its initial investigation.

Deeper analysis found the attacker had run an unfiltered view of the report, which had not been spotted to begin with because the report Okta generated had appeared to be much smaller – once the filters were removed, the downloaded file proved to be considerably larger.

New recommendations

As such, and given that Okta customer support system users tend to be privileged users in their own environments, the organisation is recommending that all customers immediately employ multi-factor authentication (MFA) and consider introducing phishing-resistant authenticators.

It has also introduced an early access feature that requires admins to reauthenticate if their session is reused from an IP address with a different autonomous system number, and if possible, customers should enable this feature immediately.

Okta is also now introducing admin console timeouts that will limit sessions to 12 hours, timing out after 15 minutes. This is being rolled out from today (29 November 2023) for preview organisations and will be generally available from 4 December.

Finally, Okta is warning customers to be alert to phishing attempts targeting their employees, but in particular to be wary of any attempts that target their IT helpdesks or related service providers. Users should also review their own helpdesk verification processes and ensure tighter checks are in place before high-risk actions – such as changing a password on a privileged account – are allowed.

[ad_2]