Cybercrime , Fraud Management & Cybercrime , Identity & Access Management

1Password Finds 'Suspicious Activity' Tied to Okta Breach

Widely used password management software maker 1Password said a hacker had breached one of its systems but failed to steal any sensitive data, including user information.

See Also: Effective Communication Is Key to Successful Cybersecurity

The Toronto-based service provider, which counts more than 100,000 business customers and millions of individual users, said it first spotted "suspicious activity" tied to its cloud-based Okta identity management system last month.

"On Sept. 29, we detected suspicious activity on our Okta instance that we use to manage our employee-facing apps," Pedro Canahuati, CTO of 1Password, said in a blog post published Monday.

"We immediately terminated the activity, investigated and found no compromise of user data or other sensitive systems, either employee-facing or user-facing," he said. "Since then, we've been working with Okta to determine the initial vector of compromise."

On Friday, 1Password said it had confirmed that the suspicious activity in its Okta software "was a result of Okta's support system breach," which allowed an attacker to steal a valid session cookie for accessing 1Password's Okta system with administrator-level privileges.

Okta, based in San Francisco, first publicized that security compromise on Friday, warning that attackers gained access to its customer support management system and stole sensitive information uploaded by some customers (see: Okta Support Unit Breached Via Credential Stolen by Hackers).

In its own incident report, released Monday, 1Password described the wider campaign: "Threat actors will compromise super admin accounts, then attempt to manipulate authentication flows and establish a secondary identity provider to impersonate users within the affected organization."

Two other Okta customers - identity and access management vendor BeyondTrust and content delivery network giant Cloudflare - reported Friday that they too had been targeted by the breach of Okta's customer support management system. BeyondTrust Chief Technology Officer Marc Maiffret said his firm's security teams had detected suspicious activity on Oct. 2, when an attacker attempted to use a valid session cookie to log into an in-house Okta administrator account.

Maiffret said BeyondTrust shared detailed information about the incident with Okta on Oct. 2 and that Okta eventually confirmed, 16 days later, that its own customer support system had been breached and that an attacker had stolen the valid session cookie from Okta.

"While there was no exposure to BeyondTrust or our customers, we are sharing details of the attack to educate other Okta users and infosec professionals," Maiffret said in a blog post.

Cloudflare said it detected this type of attack against it on Oct. 18. The company said it immediately alerted Okta that attackers "were able to leverage an authentication token compromised at Okta to pivot into Cloudflare’s Okta instance," it said in a blog post. The company said "that no Cloudflare customer information or systems were impacted by this event because of our rapid response."

Stolen HTTP Archive Files

Okta's breach involved only its support case management system, which "is separate from the production Okta service, which is fully operational and has not been impacted," said Okta CSO David Bradbury in a Friday blog post.

The company said it has directly notified all customers that were targeted via these attacks, although it has yet to state publicly how many customers were affected.

Okta said the information attackers stole from its customer support system involved HTTP archive or .har files. These files facilitate "troubleshooting of issues by replicating browser activity," Bradbury said. "HAR files can also contain sensitive data, including cookies and session tokens, that malicious actors can use to impersonate valid users."

As a result, he said, Okta now "recommends sanitizing all credentials and cookies/session tokens within a HAR file before sharing it" with Okta's customer support team."

Okta also recommends all users regularly review their Okta system logs for suspicious activity indicators. "The majority of the indicators are commercial VPN nodes, according to our enrichment information," Bradbury said.

Attack Against 1Password

In its Monday incident report, 1Password said a member of its IT team on Sept. 29 had warned its security team that the IT team had received an alert saying the team had initiated an Okta report listing administrative users, which it had not initiated.

"Preliminary investigations revealed activity in our Okta environment was sourced by a suspicious IP address and was later confirmed that a threat actor had accessed our Okta tenant with administrative privileges," the report says.

The password management service provider said it has not seen any signs that the hacker's attack progressed to the point where they could have stolen any sensitive data. "The activity that we saw suggested they conducted initial reconnaissance with the intent to remain undetected for the purpose of gathering information for a more sophisticated attack," 1Password's report says.

Immediately following the suspicious activity, 1Password said, it changed all of the IT team members' passwords, restricted their multifactor authentication capabilities to a Yubikey and locked down their Okta accounts in multiple ways.

The company said it had quickly instituted a number of other changes to its Okta configuration for all users, including changing all of their passwords, denying all Okta logins attempts from non-Okta identity providers - aka IDPs - as well as reducing the number of super-user accounts, reducing the session time allowed for admin users, and tightening MFA rules. The company also said it had added extra rules to its Datadog monitoring software to watch for additional signs of attack and compromise and to more quickly sound alerts over suspicious activity.

The attacker returned on Oct. 2 and tried to log into 1Password's Okta system using a Google IDP they had previously enabled, which failed thanks to 1Password having removed the IDP during its incident response. "It is unknown if the actor possesses valid Google account credentials that would have allowed them to complete a login via this IDP," 1Password said.

Oct. 25, 2023 09:56 UTC: This story has been updated to include details of the attack on Cloudflare.