Okta, a company that provides identity tools like multi-factor authentication and single sign-on to thousands of businesses, has suffered a security breach involving a compromise of its customer support unit, KrebsOnSecurity has learned. Okta says the incident affected a “very small number” of customers, however it appears the hackers responsible had access to Okta’s support platform for at least two weeks before the company fully contained the intrusion.
In an advisory sent to an undisclosed number of customers on Oct. 19, Okta said it “has identified adversarial activity that leveraged access to a stolen credential to access Okta’s support case management system. The threat actor was able to view files uploaded by certain Okta customers as part of recent support cases.”
Okta explained that when it is troubleshooting issues with customers it will often ask for a recording of a Web browser session (a.k.a. an HTTP Archive or HAR file). These are sensitive files because they can include the customer’s cookies and session tokens, which intruders can then use to impersonate valid users.
“Okta has worked with impacted customers to investigate, and has taken measures to protect our customers, including the revocation of embedded session tokens,” their notice continued. “In general, Okta recommends sanitizing all credentials and cookies/session tokens within a HAR file before sharing it.”
The security firm BeyondTrust is among the Okta customers who received Thursday’s alert from Okta. BeyondTrust Chief Technology Officer Marc Maiffret said that alert came more than two weeks after his company alerted Okta to a potential problem.
Maiffret emphasized that BeyondTrust caught the attack earlier this month as it was happening, and that none of its own customers were affected. He said that on Oct 2., BeyondTrust’s security team detected that someone was trying to use an Okta account assigned to one of their engineers to create an all-powerful administrator account within their Okta environment.
When BeyondTrust reviewed the activity of the employee account that tried to create the new administrative profile, they found that — just 30 minutes prior to the unauthorized activity — one of their support engineers shared with Okta one of these HAR files that contained a valid Okta session token, Maiffret said.
“Our admin sent that [HAR file] over at Okta’s request, and 30 minutes after that the attacker started doing session hijacking, tried to replay the browser session and leverage the cookie in that browser recording to act on behalf of that user,” he said.
Maiffret said BeyondTrust followed up with Okta on Oct. 3 and said they were fairly confident Okta had suffered an intrusion, and that he reiterated that conclusion in a phone call with Okta on October 11 and again on Oct. 13.
In an interview with KrebsOnSecurity, Okta’s Deputy Chief Information Security Officer Charlotte Wylie said Okta initially believed that BeyondTrust’s alert on Oct. 2 was not a result of a breach in its systems. But she said that by Oct. 17, the company had identified and contained the incident — disabling the compromised customer case management account, and invalidating Okta access tokens associated with that account.
Wylie declined to say exactly how many customers received alerts of a potential security issue, but characterized it as a “very, very small subset” of its more than 18,000 customers.
The disclosure from Okta comes just weeks after casino giants Caesar’s Entertainment and MGM Resorts were hacked. In both cases, the attackers managed to social engineer employees into resetting the multi-factor login requirements for Okta administrator accounts.
In March 2022, Okta disclosed a breach from the hacking group LAPSUS$, which specialized in social-engineering employees at targeted companies. An after-action report from Okta on that incident found that LAPSUS$ had social engineered its way onto the workstation of a support engineer at Sitel, a third-party outsourcing company that had access to Okta resources.
Okta’s Wylie declined to answer questions about how long the intruder may have had access to the company’s case management account, or who might have been responsible for the attack. However, she did say the company believes this is an adversary they have seen before.
“This is a known threat actor that we believe has targeted us and Okta-specific customers,” Wylie said.
Update, 2:57 p.m. ET: Okta has published a blog post about this incident that includes some “indicators of compromise” that customers can use to see if they were affected. But the company stressed that “all customers who were impacted by this have been notified. If you’re an Okta customer and you have not been contacted with another message or method, there is no impact to your Okta environment or your support tickets.”
Update, 3:36 p.m. ET: BeyondTrust has published a blog post about their findings.
Update, Oct. 24, 10:20 a.m. ET: 1Password and Cloudflare have disclosed compromises of their Okta authentication platforms as a result of the Okta breach. Both companies say an investigation has determined no customer information or systems were affected. Meanwhile, an Okta spokesperson told TechCrunch that the company notified about 1 percent of its customer base (~170 customers), so we are likely to see more such disclosures in the days and weeks ahead.
Wonder if Okta filed with the SEC?
Not sure, but their URL is interesting
sec.okta.com
Thinking about all these data breaches that are basically called insubstantial by the compromised entity: there needs to be cash bond put up for two years with a third party for the total number of accounts which might have been compromised. If there is indeed no exploitation or damage in that time, the compromised entity gets the money back. But if the hackers do get customer data, then customer is entitled to a payment from escrow. Rate should be meaningful but not excessive: say $ 5 per UTF character of customer data. That metered approach also encourages the entities to guard / partition data at rest better.
How were Okta’s credentials stolen this time? What was the entry point for this particular attack? I don’t see it covered anywhere. I’m confident we can assume an employee or two was compromised due to poor security controls, but we need to have it confirmed if people are to know what they need to protect.
Perhaps it’s similar to the March 2022 incident, where access was gained by social engineering into a third-party workstation that had full access into Okta’s systems.
Yet another pitfall of outsourcing: they save a little money but lose control over the 3rd party’s training and controls. And the losses (financial and image) are far greater than the few dollars they thought they were saving.
The weakest link in the chain is often that third party.
It is interesting where they say that the Okta support system was compromised. However could not see any mention of how it was compromised, what was the attack vector etc.. what is said in all the blog posts and writeups and disclosures are the HAR file that is sent by their customers to the support system, which gives the attacker all the confidential information of the Okta customer contained in the HAR file..
In other words, if the attacker had seamless access to the support system, I think we should go with the assumption that information in the support tickets for all Okta clients would have been touched and exfiltered by the attacker, given that they had access to it for 2 weeks.
securityweek _ com/okta-hack-blamed-on-employee-using-personal-google-account-on-company-laptop/
“… compromise of the employee’s personal Google account or personal device.”
Bradbury fessed up to a failure of internal controls to spot the breach. “For a period of 14 days, while actively investigating, Okta did not identify suspicious downloads in our logs. When a user opens and views files attached to a support case, a specific log event type and ID is generated tied to that file. If a user instead navigates directly to the Files tab in the customer support system, as the threat actor did in this attack, they will instead generate an entirely different log event with a different record ID.”
D’oh. Librarians fighting crime.
Isn’t Okta the authentication scheme for ISC2 now? Hilarious.
Until March 2022, Todd, Okta’s CEO, was accessing Okta systems with his personal (non-corp) laptop. He thought this was hilarious and made jokes about it at our company all-hands.
I had never worked at a company where security was taken so casually. Yubikey for employees? Nope. It wasn’t until mid-2023 that employees were no longer allowed to add external accounts to internal documents managed by Google Workspace. Our migration to GitHub Enterprise didn’t happen until July-August 2023.
The organization has so many problems, and this latest customer-facing escapade is no surprise.
“very, very small subset of it’s 18,000 customers”. Why reveal one number and not the other? Typical damage control-turned-marketing tactic.
The experience BeyondTrust had is also typical of situations where I’ve tried to report possible breaches. Everyone has so many layers of insulation between the rare person you can reach and someone that can actually understand what you’re telling them (or beyond that, care) it’s no wonder threat actors have so much time to explore and exploit breached systems. Security is everyone’s job, and everyone needs to be aware that any incident could just be the tip of an iceberg. There’s especially no excuse for it in the case of a company that’s in the security industry.
Wow, CloudFlare’s blog is great. Talk about throwing (well-deserved) shade at Okta. I’m guessing they’ve decided it may be time to dump Okta.
We have seen a number of intrusions in which the intruders got in through trusted contractors. For example, there were 22 municipalities in Texas hit by ransomware a few years ago. It seems more likely than not that the attackers got in through a trusted third party.
My small company has been approached by vendors trying to sell their security services. Being as we are small and have no need for employees to connect via a VPN, it is generally much simpler to block all external attempts to connect to our firewall. That still leaves things like phishing attacks, but we hammer in regularly not to click on links in e-mail.
Our last issue in our office network was through an outside vendor who told everyone that he was a security guru but was completely clueless about security. The most clueless thing he ever did was bring in a firewall for our network and then connected it backwards (wan -> lan, lan -> wan) and so nothing could get through in either direction. He refused to test it before leaving, but I insisted on testing it first so it only stayed connected about 15 minutes and he never tried to reconnect it.
When I took the firewall to my office and checked it out, it quickly became clear that it had the default password and rules. The only thing the rules did was to block someone from spoofing our network. Naturally, plugged in backwards, it saw any traffic from our network as being spoofed and dropped it.
1Password mentions a “suspicious IP” but neither 1Password nor Cloudfare identifies IPs involved in the incident. Okta does list IPs in their posting, which includes the IPs mentioned by BeyondTrust. I hope that Okta collected the IPs used to attack their customers and continues publishing them. I wish the sites attacked published the sources of the attacks.
VPNs are used for three distinct purposes: 1. Encrypt your traffic from/to your device to/from a trusted VPN server to avoid interception. 2. Hide your source IP from your destination. 3. Access sites from a trusted address (for instance, a corporate VPN that subscribes to services, or gives access to inside a firewall). For those VPN users for which purpose #2 is unnecessary,, I wish there were a protocol so that the VPN server could provide an identification service to identify the original source IP to the destination host. (Chaining through VPNs as needed.) Then a site could choose to permit or block a connection from a VPN server as to whether the source IP was available (and trusted).
I must say Okta had noticed very fast what was going wrong and defended them in a good way and the incident they shared benefits everyone.